Re: NetBSD cross compile from Win32?

["Andrew Gillham" <gillham%ameritech.net@localhost>]

From: "Chris G. Demetriou" <cgd%sibyte.com@localhost>:
>
> In terms of host tools, I've needed to make the following tools work:
>
> netbsd-config netbsd-install netbsd-lorder
> netbsd-make netbsd-mdsetimage netbsd-mkdep
> netbsd-mtree netbsd-rpcgen netbsd-tsort netbsd-yacc
>
> I turn off a fair number of bits (lint, man pages, etc.) in the build,
> since if you're doing embedded stuff usually you don't need those.
8-)

I was initially thinking about kernels, but of course you want to be
able to fully target userland binaries and libraries.  Not as easy as
I was thinking. :)

> The compilation tools are a mess: as far as I know you can't build
> cross-tools out of the in tree 'dist' bits (even if you want to -- I
> can't), and NetBSD support in the stock GNU tools is incomplete for
> many, perhaps most, targets, because the NetBSD-related changes
> haven't all been submitted back to the FSF maintainers.

Is this something that is planned and just needs some reminders, or is
it that NetBSD changes won't be accepted?

> Another big sticking point is file systems.  For instance, if you want
> a ramdisk image, you need to be able to _create_ that ramdisk image.
> That's not necessarily going to be easy unless you have a NetBSD host
> around -- there are no good tools to make a BSD FFS at this time.  If
> people want to implement that type of thing, I'd love to see it -- and
> would be glad to provide ideas for what should be in it.

I haven't really liked the mdsetimage method and would prefer to see
the kernel and ramdisk seperated and loadable.  I can see the benefits
of
a single binary blob that contains the entire system though, so I guess
options are important.

This is probably a lame thought, but how feasible would it be to use the
USTARFS support rather than FFS for the ramdisk image, and then use
mount_mfs to dynamically create the root filesystem and populate it via
the tarball?  It seems like the kernel could even untar using a tar
binary inside the tarball rather than inside the kernel.  (Provided the
vnode to the MFS could be passed to tar?)
Then it would not be necessary to make an FFS image, just a tarball,
and cygwin certainly can do that.  If the tarball was just appended to
the kernel somehow, the memory might even be recoverable after the the
MFS is populated.
Also for platforms that can boot from a USTARFS, it might even
be possible to just 'tar clf blah /' to build the boot image. :-)

-Andrew