In message <[EMAIL PROTECTED]>, Andrea Campi writes:
>> >> I think it's the time to throw i386 over the railing and lower the
>> >> waterline a fair bit on -current.
>> >Does it make any sense at all to make 80386 a separate platform
>> >a'la pc98/alpha/ia64? Do enough people care about it?
>> No it doesn't. I think you'll find that running 5.x in less than
>> 32MB is going to be painfull or impossible in the first place.
>Sorry Poul, I think the question here is: "if we decide to remove i386 support
>BUT a few people still want to use it and can maintain it as a separate
>platform port, is it an option to do so, from a technical point of view?"
>Personally, I don't care about i386 support in -current, but if it's possible
>to keep it in parallel, then why not?
(This is a general answer, not just about i386 support:)
Any feature in FreeBSD needs a minimum amount of maintenance. If
nobody cares about some particular bit of code, it will slowly of
quickly rot away.
It's not that the actual bits themselves change, but FreeBSD changes
around them all the time. APIs get tweaked, usage models change,
all the time, a continuous growth process.
If nobody has the hardware to test it on, *and* the inclination
to do so, it will not get tested, and the code will erode as a
I have a 386SX/20 CPU, but I'll be damned if I can be bothered
to boot FreeBSD-current on it, in fact it didn't even boot
a 4.x last I tried.
Any feature can survive in FreeBSD if sufficient manpower is spent
maintaining it: If you came in with 10 dedicated and able hackers,
you could get a VAX-11 architecture into FreeBSD.
If you can muster the people needed to write the increasinly quirky
assembler code replacements for features the i386 CPU doesn't have
I'm sure you can keep the i386 alive for some years.
The reason against doing so is that it complicates our code. Makes
it less readable. Forces us to make tradeoffs which hits modern
hardware on the performance meter.
Yes, like anybody else I'll be sad to see i386 support go, but
hey... none of my i486 systems can even boot the current install
floppy anymore, I think you need 32MB RAM for that and I only have
16MB in my systems.
If we should do anything for the i386, it should be for some
intrinsic value that particular chip has. Apart from maybe the
rad-hard and possibly VHDL-macro aspects, the only unique property
the i386 has for me these days is "history".
I don't do satelites, I suspect most of you don't, and I suspect
those of you who do know just how far FreeBSD-5.x will be from that
market segment for some years to come.
If you design something with a VHDL i386 core these days, I bet
you're not trying to load it with a unix kernel anyway. If you
are you'll have so many tweaks already, that I doubt you would
want to look at FreeBSD 5.x for your one-chip design.
Personally I would not really find it interesting to have a BSD2.X
style "FreeBSD-lite" created for the i386 for mostly sentimental
reasons, and I have a perfectly good reason for that: My i386 box
has that one last intrinsic feature served much better with the OS
I have installed on it: "386BSD 0.1newer + patchkit".
Not only does it boot in 20 seconds flat but most importantly it
reminds me how far we have come in the last 9 years by sweeping
the broom every so often.
As David Scheiffler wrote in his X11 book:
"It is as important to decide what a system is not as to
decide what it is. Do not serve all the world's needs;
rather, make the system extensible so that additional needs
can be met in an upwardly compatible fashion."
PS: Anyone with a i386 box is welcome to send me email if they want
a copy of 386bsd and the patchkit
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message