Steve M Bibayoff wrote:
Hello,
On Mon, Jun 23, 2008 at 1:23 AM, Andrew Lentvorski <[EMAIL PROTECTED]> wrote:
You can maintain a stable API or even ABI *even through massive
revisions*.`--see FreeBSD,
From FreeBSD 7.0 Release notes:
"Several minor but widespread changes to the Newbus API have been made
In order to support some on-going work with interrupt filtering.
Because this change also breaks the kernel ABI, all third-party device
drivers will need to be modified and recompiled."
http://www.freebsd.org/releases/7.0R/relnotes.html
And you will note that *THE MAJOR VERSION NUMBER CHANGED BECAUSE OF IT*.
FreeBSD won't even upgrade gcc versions until a major version number
upgrade for exactly this reason.
This is in stark contrast to Linux where 2.6.12 to 2.6.13 can completely
trash your drivers.
No one is saying that Linux should be static forever. However, it
should present a stable API/ABI for some length of time, batch up
changes that it's waiting for, and then bump major versions when it does
something incompatible.
And, BTW, this is happening to a certain extent. The fact that
distributions like RedHat choose a kernel version and then stick with it
for a long time effectively does this. The problem, of course, is that
each distribution that wants stable doesn't really know which kernel
version to lock onto. So, they pick one and hope the choice wasn't too bad.
I haven't checked, but I doubt a driver for earlier versions of
Solaris(SunOS) and AIX would work on never versions.
I'm pretty sure you would be wrong in the case of Solaris. I have seen
some really old hardware run on very modern versions of Solaris.
Normally it's some stupid hardware dongle for piracy protection.
On AIX, I *know* you are wrong. IBM has hardware that will translate
interfaces to hardware that is *very* old. I have seen *ancient* punch
card readers connected to modern hardware and it still works.
Of course, nobody knows the formulation for the rubber wheels on those
machines anymore, so we now use scanners and autofeeders.
Are you implying that NO Linux kernel hackers use any type of
regression testing? And that there is NO Linux kernel tests?
I sure don't see any in the kernel source. There is no "make check" or
"make test" that runs even a basic scan.
Some of the maintainers may keep their own somewhere else. When I was
working on the rpc.lockd for FreeBSD, the Linux version was quite
clearly broken if you ran any test against it.
This doesn't force drivers to be included into the kernel,
but it does entice them to. This way the person who changes a kernel
API is also responsible for for changes all the drivers that use that
API.
Right. Since there are no tests, the only "test" is to put it in
mainline and see if people squawk.
That's great for hardware that gets lots of use. Not so good for
hardware that doesn't.
As far as the "ethernet adapters" stability goes, it wasn't because
the kernel API became stable, it was because (almost) ALL of the NICs
code got merged into the mainline Linux kernel tree.
No, it was was because one particular developer stood like a bulldog
over that API and beat anybody over the head who changed it. Once
everybody knew that API was stable, they wrote all their drivers to that
API and added even more inertia to it.
There were *lots* of NIC's in mainline before Donald Becker. Somehow
that never helped.
If you haven't read it yet, another Greg K-H rant about kernel
development myths:
http://www.kroah.com/log/linux/ols_2006_keynote.html
Quoting:
"Now, this is true, it would be great to have a simple set of tests that
everyone could run for every release to ensure that nothing was broken
and that everything's just right. But unfortunately, we don't have such
a test suite just yet. The only set of real tests we have, is for
everyone to run the kernel on their machines, and to let us know if it
works for them."
Translation: We don't have tests. We're not going to write tests. We
don't even want you to write tests. You are the tests. Have fun!
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
