Quote of the week [LWN.net]

Quote of the week

Posted Dec 16, 2004 19:26 UTC (Thu) by gregkh (subscriber, #8)
In reply to: Quote of the week by elanthis
Parent article: Quote of the week

Sorry, but no, we do not keep old, broken, unsecure apis around. If they are broken, we fix them. If they are unsecure, we fix them. Both of these reasons are why we do not, and will not, have a stable in-kernel api.

And as for "why not just do this for drivers?" Remember that drivers are first-class kernel citizens. There is no difference to the kernel from a USB driver, or a filesystem from the point of view of the code.

And if you want to upgrade your enterprise release kernel's drivers, then talk to your enterprise distro about this. You are staying with a specific kernel version for some reason, and that has nothing to do with the way the kernel developers work.

And if you want to upgrade your wireless card's driver version, then talk to those developers about providing support for older kernel versions. I'm sure if you want to pay them, they would be glad to offer this kind of support :)

(Log in to post comments)

Quote of the week

Posted Dec 16, 2004 20:35 UTC (Thu) by mrshiny (subscriber, #4266) [Link]

I guess what you're saying is that the way kernel developers work is not the way users use the kernel.

Don't get me wrong, I think you and the rest of the Linux kernel team have done lots of great work. But, especially since there doesn't seem to be a stable kernel anymore, I feel that needs of the users are being forgotten. The users are staying with particular kernel versions because the kernel is a tool that gets a job done, and replacing the whole kernel to upgrade a single driver is a bad idea from a risk management perspective. Business users don't want variability, they want predictability. In the case of a kernel, if the kernel has a buggy api, so be it, if the kernel is getting the job done. Users don't care about API, or deadlocks. And a deadlock that occurs for other users but doesn't occur for me is irrelevant to my business.

As a kernel developer, you want to eliminate deadlocks and other bugs. But if a bug is not manifesting itself to all users, eliminating that bug at the cost of every user's drivers is a high price to pay. By increasing the functionality of the kernel for some users, who experienced a flaw, you reduce the functionality for other users (binary module users), who can no longer use their hardware, and you make life more difficult for the third class of users who want to use new hardware on an old kernel, but can't because the drivers need to be back-ported. You have to admit: in many cases it is possible to maintain backwards compatibility (at least on a source level) without jumping through hoops, even if an API is broken, or easy to mis-use.

Stable releases

Posted Dec 17, 2004 2:17 UTC (Fri) by mbp (guest, #2737) [Link]

There is a stable release: 2.6.8.1 works great for me. (ymmv) I'm going to stick with it until I need a new driver, or I get bored. The same strategy can work for you: find something that works, then quit fiddling. If you want stability, stop upgrading.

Having a stable release series is not meaningful when the user community is as diverse as for the kernel: what works well for you may be inadequate for someone else. Maybe you need support for new hardware, but to me that's just dangerous churn. Who gets to decide what is critical enough to go into the stable stream?

Stable releases

Posted Dec 17, 2004 13:03 UTC (Fri) by mrshiny (subscriber, #4266) [Link]

This is why the kernel needs a stable release, and drivers need to be
released separately. If the kernel itself is working for you, you don't
upgrade it. But if your drivers are inappropriate, you get new ones, and
install them on your older kernel. Unfortunately we can't do that in the
linux world because the kernel developers have decided (rightly or
wrongly) that they don't want to support that use-case. Why should I
need to upgrade my whole kernel to get a network card working? What if
that network card is newer than my kernel, and the driver only exists on
a newer kernel that doesn't have the same driver api? I am out of luck;
even though my kernel works fine, I want to upgrade a single component in
my whole computer but I now have to upgrade the whole kernel, and ALL the
device drivers. What if a device driver I used to use is now broken?
It's happened in the past.

Stable releases

Posted Dec 17, 2004 20:11 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

This is why the kernel needs a stable release,

Exactly. However, some of the discussion here seems to suggest that Greg and his peers should provide it. There's simply no reason to expect that.

Instead, we need distributors, whom we pay to give us what we need, to provide a stable release. They can take high-reward low-risk changes from kernel.org and add those, and they can skip compatibility-busting changes (or, more likely, make the minor modification required to make the change backward compatible).

Since distributors used to get a lot more free help with that from kernel.org (via the e.g. 2.4 "stable" series) than they do now, I'm still waiting to see if they step up to that responsibility with 2.6-based kernels.

Quote of the week

Posted Dec 20, 2004 17:30 UTC (Mon) by mwilck (guest, #1966) [Link]

You are ignoring the fact that a lot of important drivers, even if GPL, are developed out-of-tree, mostly by hardware manufacturers. This holds even for the venerable aic7xxx/aic79xx which used to be tied into the kernel very closely, but isn't anymore now.

These companies develop their driver code independently, and try to merge them into the mainline kernel once in a while. Usually they try to support a large range of kernel versions with their driver, both vanilla and vendor kernels. These codes quickly evolve into a nightmare of #ifdef's and #if LINUX_VERSION_CODE <= KERNEL_VERSION(...) constructs.

However, what else should a driver developer do? Hardware suppliers can hardly demand from their customers to always stick with the latest -mm kernel. They can't rely on RedHat or Novell to back-port the drivers for them, either, because RedHat and Novell have their own agendas.

IMO the very least kernel developers should do is make the different API versions cleanly discernible by CPP macros. That doesn't mean the old API has to remain in place, there must just be some CPP macro that the driver code can test that says the API has changed. E.g. if a field "foo" is added to "struct bar" then the respective patch should contain a line

#define __STRUCT_FOO_HAS_BAR 1

(or similar, you get it).

I know CPP is ugly, but this is the only safe way for external driver-suppliers to follow development without breaking things completely for older or vendor kernels.

I predict that sooner or later someone will have to come up with some sort of "kernel autoconf" tool only to be able to maintain a minimum level of source-code compatibility between the kernel core and drivers. That'll be a pretty sad day.

I am 100% for GPL drivers and 100% for improving the kernel at max speed. But to gloat about breaking the interface for external suppliers goes too far, and shows a lot of ignorance for the needs of everyone except the core developers.