Eduardo Horvath <eeh@turbolinux.com> writes:
> [Can you actually support running a process in other-endian mode without
> breaking things on (say) mips4?  Especially re: file I/O?]

it's certainly technically possible to run other-endian user-mode
binaries on a given CPU.  i've not tried it.  NetBSD certainly won't
do this, but there are a lot of things about which that can be said.
8-)


> How are you handling this now?  Is is viable long-term having
> /emul/mipsel32, /emul/mipseb32, /emul/mipsel64, /emul/mipseb64, etc?

I'm not using any normal netbsd mechanism at this point.

NetBSD on mips currently 'normally' uses, basically, -mips1 with some
bad variations on floating point (and there, they've mostly been
phased out as far as I can tell because of the difficulty people have
encountered managing the different binary sets)

As far as I'm concerned, the way that GCC multilibs do this are
acceptable to me, or close enough that i'm not going to worry about
it.  that is, basically, put things in subdirs of the 'lib' dir based
on options.

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.

	* 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.


cgd