On 10 Jul 2000, Chris G. Demetriou wrote:

: putting things into 'emul' like is broken, as far as i'm concerned,
: for a couple of reasons:
: 
: 	* native binaries are native binaries, they're not emulated,
: 	  regardless of the particular width of a few basic types.
: 	  i.e., it's logically bad to claim that they're emulated.

That depends on how you define "emulated".

SPARC (32 bit) binaries running on a sparc64 system cannot use the "native"
sparc64 shared objects; you can't take a 64-bit /usr/local/lib/libfoo.so and
expect a 32-bit sparc binary to be able to dlopen() it, for instance.  They
also cannot share structs in shared memory with "native" sparc64 binaries,
and have to have most arguments translated at the syscall-entry point in
order for the kernel to understand them.

I certainly call that emulation.  The only non-"emulated" things are the
fact that the 32-bit sparc binaries know about the same directory structure,
presence of the same commands available through exec(), and same basic
number of syscalls.  Were it not for the stuff in compat/netbsd32, these
things wouldn't run.

: 	* at some point, the hair around keeping lots of directory
: 	  trees, just for the sake of different libraries, etc. is
: 	  pretty bad.  then there are all of the issues around
: 	  path lookups, etc.

This is not really relevant to the question at hand, as you're arguing to
/emul vs. /usr, to which I personally don't care.  I like /emul only because
it preserves the path structure of the target system whose binaries are
being executed.

The issue here was whether a sparc64 system would have 32-bit libraries in
/usr/lib (even though userland, and the compiler's default, would be
otherwise 64-bit binaries), and the 64-bit libraries in /usr/lib/sparcV9 --
and the added hair for that (making ld _not_ use /usr/lib by default,
hacking ld.elf_so, building src/lib specially for sparc64, etc).

-- 
-- Todd Vierling (tv@pobox.com)