At Tue, 11 Sep 2012 00:27:36 -0400 (EDT), Mouse
<mouse%Rodents-Montreal.ORG@localhost> wrote:
Subject: Re: 80386 support
>
> > 1. It really probably is best to think of "small machines", be they
> > old or not, as "embedded" targets to some degree, particularly if one
> > wants to run any significant portion of NetBSD on them. That does
> > mean cross-compiling, of course, but that's trivial to do these days.
>
> Best? By what metric?
Best by the fact that if you want to use a reasonably modern NetBSD then
that's the only way you're going to have much fun, and possibly the only
way you're going to even have any luck whatsoever.
> For the sorts of purposes for which I'd consider running NetBSD, if it
> can't self-host, it's broken.
That does not compute for me. Even if your purpose is only to work on
NetBSD itself, there's still no need to try self-hosting it on tiny
hardware.
The only time "self-hosted OS" ever really meant anything to me was when
I had only one computer and when cross-compilers were few and far between.
Even before cross-compilers I would still often choose to build binaries
on beefy machines and install them on lesser ones for production work.
E.g. I never built the kernel for my diskless Sun-3/60 workstation on
that machine itself, but rather on the big Sun-3/280 in the basement!
Why would making NetBSD work on any other tiny and/or tiny&old system be
any different?
As for compiling applications on such a small system, well obviously GCC
is out, but perhaps with PCC it will still be possible. I do plan to
include PCC in a version of my crunchgen binary at some point, but it's
not quite there yet, especially for NetBSD-5. The whole toolchain
shouldn't increase the size of the binary by much, but the filesystem
will have to expand considerably to hold all the libraries. I'm still
not sure what to do about dynamic linking. I'd rather not include ld.so
in my crunchgen'ed world at all. X11 is another "issue" I'd like to
tackle.
> ...and don't care about more than booting and maybe running a couple of
> tiny programs.
Tiny? By what measure are you considering "boot to multi-user with
networking daemons enabled" tiny? Once you get that far you should be
able to read and send e-mail, write documents, etc., probably even
hosting multiple users doing the same.
> A 12M ramdisk (plus the kernel) isn't my idea of "_really_ low". My
> idea of "_really_ low" is more like 2M.
With secondary storage for the file system you might get away with 2MB
on some very limited hardware (i.e. few devices), and perhaps without
networking, or at least any of the more useful networking features, such
as IPF, NFS, etc. Just for fun I tried configuring a very limited
kernel which should match the bare minimum 80386 system with just one
disk controller and just one ethernet interface and I ended up with the
following:
text data bss dec hex filename
1071928 37956 362292 1472176 1676b0 netbsd
That's pretty small, but it still may not boot multi-user in 2MB of RAM,
even with my super all-inclusive crunchgen binary. 3MB, no problem!
However I don't think I ever ran any kind of unix on any 32-bit machine
with just 2MB of main memory, or if I did it was just to see if it could
boot.
I'm pretty sure we had at least 1MB of RAM even on 286's running Xenix
which was basically all 16-bit code at the time. The last PDP-11
running Unix that I used had 4MB of memory.
4MB is _really_ small these days, when the average SoC system of similar
capability comes with 128MB!
If you want to run on anything smaller than 4MB of RAM then you'd have
to toss out all networking I think.
> Only for those for whom having to always cross-compile *can* be A-OK.
Why would you ever care if you _always_ have to cross-compile????
For real hardware that's both tiny and old the benefits of cross
compiling are enormous, and the benefits of self-hosting are, well, nil
null and void when you come to think of it.
The only real excuse for self-hosting on a tiny machine is when that
tiny machine is still the most powerful machine within easy walking
distance.
> In particular, resurrecting 80386 support as a separate port (which I
> think I saw mentioned upthread) is rather difficult with the obvious
> port name already in use by a port it no longer really applies to.
For practical purposes it could perhaps be called "r386" for "real 386",
or "iAPX386" to match the original Intel nomenclature, or "gd386", or
even just "80386", etc., etc., etc.. There's nothing "difficult" about
it, really. Here naming isn't really the issue, despite what I said
about feeling that it could and should still be changed. Making the
naming of the "new" port a "difficult" contention point is a bad excuse.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgp9AMMA_oRYi.pgp
Description: PGP signature