From owner-freebsd-current Sun Jan 14 14:17:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 4FDD637B400; Sun, 14 Jan 2001 14:17:25 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0EMFM964229; Sun, 14 Jan 2001 14:15:22 -0800 (PST) (envelope-from dillon) Date: Sun, 14 Jan 2001 14:15:22 -0800 (PST) From: Matt Dillon Message-Id: <200101142215.f0EMFM964229@earth.backplane.com> To: Poul-Henning Kamp Cc: Andrea Campi , developer@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf GENERIC References: <31573.979509396@critter> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message