: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.

    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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to