: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
:result.
:
: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.
:...
I'll just point out here that the situation we wind up placing ourselves
in re: keeping the 386 support capability, but removing it from GENERIC,
is no different from the (positive) situation we place ourselves in when
we slow or stop support for older releases after rolling newer ones.
There are still people actively using 2.2.x, and even more people using
3.x. But the development community as a whole does not bother to do
full compatibility testing of their work when MFCing to 3.x or 2.2.x
any more. Most in fact don't MFC bug fixes to 2.2.x or 3.x at all.
There is nothing wrong with this, just as there is nothing wrong with
leaving the 386 cpu support intact as long as it does not interfere
with current work.
All that is happening here is that the burden of continuing support for
these older releases and cpu's shifts from the development community to
the people still actively using those systems. This is entirely
reasonable. There is no reason for us to gratuitously rip out support
for anything that might still be in active use, even if we are no longer
actively developing for it. As long as the support in question does not
interfere with our own work, we might as well leave it intact.
In fact, I think many of our customers rest easy at night knowing that
some level of support still exists for these older releases, that they
can continue to support the older releases themselves, and that
nobody is intentionally trying to nix the support.
-
I'm going to leave you all with an anectdote. When Motorola finally
decided to stop manufacturing non-integrated 68000 core's some of their
largest customers (who were still using the core's) asked motorola to
re-specify the timing and frequency limits. You see, even though the
design was old Motorola was producing the 68000 core's with modern chip
fabs, but all the timing specs were 15 years old. Many of their
customers were actually running the chips at higher frequencies then
spec because, well, it seemed to work just fine.
Motorola tested the 68000 core and found that they could operate a
12.5 MHz 68000 core at 60+ MHz before it crapped out. This delighted
Motorola's customers.
Despite its age, the 386 has a number of things going for it. You can
produce it extremely cheaply as part of a larger chip, and you can run
such 386 implementations much faster then you would think. The 386 may
be dead to the consumer world, but it's still kicking away in the embedded
world - and it isn't just because there are rad-hard versions of it
available. The 486 has only just recently started to supplant the 386
in the embedded and aerospace worlds.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
