Re: 80386 support

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> I expect it _will_ prevent people from working on non-privileged-tier
> ports, because anyone trying to will be - probably repeatedly - screwed
> over by people making changes to the main tree that don't work, or are
> unacceptably expensive, for such ports.  I know it sure demotivates
> _me_ to even try, knowing that keeping modern NetBSD running on (say)
> sun3, or vax, is going to be a constant fight to find workarounds for
> things committed by people who don't care about the effects they have
> on such ports - and that's just to keep it running, never mind actually
> make any progress.

As for supporting sun3, i386, etc - perhaps you have a wrong impression.
It was stated before that NetBSD is not a conservation project nor its
primary goal is to run on the old computers (however, let me just be
clear - this does not mean that we should not support them - see below).
There are other active projects (e.g. 2.11BSD revivals) which have such
goals.  Don't they suit your needs better?  However, if you live in some
alternative world of the past and according expectations about NetBSD,
then I am afraid it will be more and more difficult for you to cope with
the world changing around you as time goes by.

> I recently discovered that as of 4.0.1 a 32M x86 machine can,
> effectively, no longer self-host, because the compiler thrashes for
> hours trying to compile one of the source files.  Fortunately that
> machine had upgradeable memory, and I had memory to add to it.  But I
> have an hp300 with a grand total of five megabytes of RAM.  I'm
> unlikely to ever find more memory for it, certainly not much more.
> Last time I tried to boot it, there was approximately one megabyte left
> for userland.  That machine would be majorly screwed over by people
> working on multi-gigabyte amd64 boxen thinking "who cares about another
> 64K?".  And now that NetBSD is no longer willing to tell such people
> "no, you can't do that, it breaks these other machines", it amounts to
> abandoning support for such machines.
> 
> There's another machine I have which is in a similar situation with
> disk space.  As far as I know, no interface hardware exists at all
> (much less is commonly available, even as comared to the machine
> itself) to allow it to use even IDE, much less SATA, disks; "how much
> does that much disk space cost these days? $0.00005?" is simply
> _wrong_.  Yet I've been seeing that sort of remark for years, and now
> it has NetBSD's backing behind it.  That machine is another of the
> second-class citizen ports.  I expect it to be dropped within a few
> years because it's broken - well, duh it's broken, NetBSD no longer
> cares if people break it!

Many (most?) developers, including myself, care about the memory usage,
especially as one of the NetBSD's targets is embedded systems.  Different
ports may have different tuning and memory expectations, though.  For
instance, amd64 or sparc64 can assume more memory.  However, if MI code
is too hungry on a system with 32MB of RAM, then I think we ought to
investigate and fix or improve that.

It should also be noted that other software increases its minimum
requirements or changes assumptions about the memory as well, and often
in quite more significant way than NetBSD.  Recently I was surprised to
see gcc killed on my 2GB laptop by UVM for running out of memory, after
I disabled and forgot to enable the swap.  Unfortunately, recent gcc is
that memory hungry!

As for disk space - I am one of those who has been advocating to not
import more stuff into the base, in favour of modularity and packages,
and better support of the packages..

> Perhaps that is not how core will treat such things.  But in that case
> the announcement was pretty catastrophically badly worded, because it's
> sure the impression it leaves.  And it seems to be the effect it's
> having; less than a week ago, someone discussing a proposed change said
> "Well, that covers most of the Tier I ports, which I think is good
> enough.".  Not totally unreasonable in that particular case, but an
> illustration of the attitude - note it wasn't "...which I think is good
> enough in this case".

Right, I wrote this.  There are good reasons why decisions to not support
some port are made, and they are not just because it is "old".  You
mentioned acorn26 or sun2.  Good examples.  The only user and developer
of acorn26 we know became inactive and not even contactable.  We know 2
users of sun2 (one ran it on emulator, wow!), there may be more, but we
are not aware of them.  Both ports are unmaintained, quite rotted, sun2
and sun3 (in fact, most of m68k based ports) being horrible copy-pastos
all over the place, making a good headache for MI developers when some
API needs to be changed or updated.

VAX, on the other hand, is maintained by matt@ and although we make
jokes, I do not think anybody has a trouble with the port, when it is
reasonably maintained.  Yes, we do not design MI to be VAX-centric,
nor matt@ is trying to push that.  There are various reasons for that
as well (if you think that code can *perfectly* suit all ports without
having a huge maintenance headache or code readability problem due to
special cases everywhere or without penalising performance some ports,
then you are wrong; one could write an essay thoroughly explaining why,
but I think for most developers it is quite obvious).  Just to be clear
again - it does not mean that one could not achieve a decent level of
abstracting and suiting our platforms (I think NetBSD is very good at
this in comparison to other OSes, but we cannot be perfect either) and
it does not mean that we do not strive for well engineered code, we *do*.

Anyway, given the described maintenance problem with acorn26 and sun2,
you expect somebody to write and more importantly maintain BPF JIT for
these ports?  Who will do that?  Do you expect others (i.e. not those
few who might actually be using them) to do it?  If you care about a
port with couple users, then why do not you maintain it?

-- 
Mindaugas