[lkml]   [1999]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux headed for disaster?
"Kendall Bennett" <> said:


> 1. A later version of a kernel may well have introduced new bugs
> into a previously stable driver. Solving this problem currently
> requires the user to revert back to an older kernel revision. Doing
> so may not be desireable because the new kernel version may have
> updates and fixes that are desired. With binary portable modules, the
> module a previous kernel that did work could be used in place without
> problems (ie: it is expected to work if unless there is an interface
> change).

Then the driver source code can be dropped into the newer kernel anyway.

> 2. Binary portability requires more solid and clearly defined
> interfaces between the kernel internals and the modules themselves.
> By requiring that there be a clear separation or 'firewall' between
> drivers and the kernel internals, you can more easily avoid the
> classic problems of coupling where changes in some other part of the
> code affect other code that should not be affected. Specifically it
> makes it impossible for a driver to implement a 'quick hack' solution
> by accessing the internals of some other driver or the kenerl
> directly. However the *only* way to enforce this is to design device
> type specific binary API's, and *require* that the only way a device
> driver can talk to the kernel is via these API's.

This makes some sense. But it also hinders development.

> 3. Binary portability means much less regression testing is required
> for new kernel versions.

It just means the module links into the kernel, not that it did not make
some unwarranted assumption that used to hold, but does not anymore. Might
be somewhat less, but never dissapear.


> A clear case in point in my book in the hardware compatibility as
> reported by Red Hat on their web site. Go to the Red Hat web site and
> check out the hardware compatibility list for network adapters. Red
> Hat has the concept of 'Tier 1', 'Tier 2' and 'Tier 3' supported
> hardware. Their definitions for this are:

Note that this has little to do with software quality, it is mostly about
hardware problems. For example, there are truckloads of different NE2000
clones out there, most of them broken in subtly different ways. To build a
single driver that works (sort of) with most of them is a titanic task. The
wonder is that it _does_ mostly work, but nobody in sane mind would
guarantee anything. Sure, if each of them had its own driver, things might
be different. But then the maintenance nightmare blossoms elsewhere: "Why
does driver ne2k-10157a not work here?" (They needed ne2k-11057c), "Need to
fix all ne2k-* for <insert favorite update here>"


> Now look at the Tier 2 list. This list is rather larger, but surely
> more of the adpaters in this list *should* be working better, since
> they have been around for some time and hence the drivers *should*
> have stabilised by now? I am sure Red Hat would not list hardware as
> Tier 2 unless "some users have reported problems with some versions
> of this hardware, or with the hardwares interaction with other
> hardware".

"Some users have reported...", and RH has no way to confirm or deny all
reports they get. PCs are a wonderfully varied pack. You can even buy two
cards (and even complete machines) that are traded as the exact same make,
model and so on, that are _totally_ different inside. Seen that with PCs
from the very same batch from the manufacturer, BTW.


> Constrast this again with FreeBSD whose development methodology
> actively supports binary portable kernel modules. Perhaps now it
> makes more sense why FreeBSD is considered more stable than Linux and
> that so many web servers run FreeBSD and not Linux. FreeBSD does not
> support as much hardware, but for what it does support, it is more
> stable.

Have you compared stability with tier 1 hardware for Linux, and the
equivalent for BSD? Just curious. Also, it has been stated that *BSD have a
_much_ smaller user base, and more knowledgeable users with higher-end
machines, so some classes of problems simply won't show up, which makes
sense to me.
Horst von Brand
Casilla 9G, Viña del Mar, Chile +56 32 672616

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.105 / U:12.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site