On Thu, Oct 25, 2001 at 05:06:40PM -0400, Greg A. Woods wrote:
> 
> Using some foreign software as a terminal is one thing -- using it as a
> cross-development hosting environment is quite another (no matter how
> POSIX-ish you can convince it to be with add-on tools!).  If the
> underlying filesystem in the host environment is not capable of at least
> supporting all possible filenames a Unix native host can support then
> that's a very good indication that your undrelying host environment may
> not be best suited for cross-development of a Unix(-like) OS!

Don't get hung up on the cross-development issue.  Think more about the
idea of "targeting an embedded environment" where the only NetBSD in the
place might very well be the embedded system.

> One would think that cross-builds are best suited for getting kernels
> and user-land prepared for new ports while being hosted on existing
> ports, not for building new ports totally within foreign host
> environments.

Depends on your goals.  If you are building an embedded product, I think
you are interested in getting a working kernel and some other custom code.
Not necessarily "user-land" as we all know it.

> It's one thing to want to be able to build a kernel and enough of
> user-land to start up the self-hosting process on any arbitrary platform
> with a suitable C compiler on-board, but to desire to build all of the
> system on a foreign OS base should be nothing more than an interesting
> academic experiment, but unsuitable for general consumption!  [0.001 :-)]

Sure, I'll cross-build from Windows to the Acme Widget with 8MB of RAM.
Once I have a working kernel, I'll get user-land self-hosting and then
do all of my work right on the 75Mhz Widget by NFS mounting over the USB
connection.  After all it would be foolish to use my 2Ghz SMP desktop with
2GB of RAM, since there are some filenames that can't be represented by
my inferior OS.

Personally I think changing names from "cmd" to "command" is much better
anyway, since we can support the longer names why not use them?  Losing
some names like "aux" is a small price to pay for the ability to provide
support for embedded type work to the people that are looking at VxWorks,
or WindowsCE, or Windows XP embedded.

We _want_ those people looking at NetBSD and using it in the next Widget 2000
right?  We're not _trying_ to chase them off because they use an "inferior"
OS on their existing development systems are we?

I will agree that it is possible to go too far with this, but the steps
taken so far seem perfectly reasonable to me, especially considering the
amount of prior art there is.   E.g. we support their filesystems, we support
their executables somewhat, we even have binaries compiled on the their systems
in the CVS repository, right next to the VisualStudio project files to allow
the binaries to be rebuild easily.  Changing some filenames seems much 
cleaner to me than the "taint" of all those foreign files. :)

-Andrew