Quote of the week [LWN.net]

Maintaining drivers out of tree is shameless autoflagellation at the best of times. We really don't care -- if we didn't make life hard for them in this way they'd only go and stick pins under their fingernails to make up for the lack of pain. If you think about it like that, we're probably doing them a favour -- at least this way they're _safe_.

-- David Woodhouse

to post comments

Quote of the week

Posted Oct 12, 2006 8:39 UTC (Thu) by Frej (guest, #4165) [Link] (25 responses)

So what do I do when:
1) buy a webcam
2) find out there is no driver in my 3months old distribution but in upstream kernel

This system works great for the user!

Ofcourse I could have checked first, but come on. A driver that works for real people would be nice.

I'd rather have a crappy driver that does what I need, than a beautifully engineered one that isn't available to me.

Quote of the week

Posted Oct 12, 2006 9:14 UTC (Thu) by khim (subscriber, #9252) [Link] (16 responses)

Then you go and grab "upstream kernel". Really, it's no big deal. RMS is not joking when he says that "Linux is just a kernel" mantra. This is not a joke, that's reality on one system I'm using (extreme, I know, but there are also RedHat 9.0 with 2.6.17 and few versions of Slackware, it's just the oldest system still in use where I work):
$ uname -a ; cat /etc/redhat-release
Linux srv 2.6.17.6 #1 Fri Jul 21 17:41:50 MSD 2006 i686 unknown
Red Hat Linux release 6.2 (Zoot)

From the user perspective kernel is the collection of drivers. If you need new driver - just install new kernel!

Quote of the week

Posted Oct 12, 2006 15:22 UTC (Thu) by mrshiny (guest, #4266) [Link] (13 responses)

What a good idea! That's excellent from a quality assurance perspective. I'll upgrade my WHOLE KERNEL, including ALL drivers, just to get ONE driver. Absolutely NO way that might cause problems. There's ZERO chance that new drivers for my existing hardware might be broken in a new kernel, and ZERO chance that the new kernel might be less stable than the one I already have. Of course! I'm so glad you explained this to us.

Please excuse my snarky attitude but frankly, the whole "just upgrade the whole kernel" thing has got to stop. The kernel devs can do what they want, I'm not paying their salaries, but it's 100% clear that users want and need drivers separate from the kernel, and I, for one, am a little tired of people telling me I don't understand my own requirements.

Be realistic

Posted Oct 12, 2006 23:28 UTC (Thu) by i3839 (guest, #31386) [Link] (10 responses)

Two options:

- Someone is going to backport the new driver to the kernel version you're using. Not only that, but also to all other old versions that people might still be using, or else not everyone is happy. This is a lot of work, not to mention that all those backports aren't as well tested as the new one with the new kernel, so the chance of working is much smaller. It will also get much less testing, so less bugs will be found. All that time and effort is better spend in making sure the new kernel is better than the old one.

- Have a stable binary API for modules. See stable_api_nonsense.txt in your kernel source, or at kernel git http://tinyurl.com/y724vj.

Any better ideas?

I don't see the problem, really. You prefer to hunt for individual drivers instead of having everything work automatically? If you don't want to download all those Mbs to get a few driver, then your distro should package the drivers seperate from the kernel, and automatically download missing drivers when needed (not too hard to do with udev and friends nowaday, as long as the network is running).

And how often does it happen that you get new hardware that isn't supported by your old kernel anyway? Few times a year?

A lot of people are working quite hard to improve the kernel everyday, why would they do that if the new kernel wouldn't be better than the old one, you think? Sure, something might have broken, but no one will know as long as the kernel isn't used and the chance of existing drivers breaking is smaller than the chance that a backported driver breaks. You lose some, you win some, but overall there should be improvement.

Stable API Nonsense nonsense

Posted Oct 13, 2006 0:57 UTC (Fri) by mrshiny (guest, #4266) [Link] (9 responses)

See, everyone keeps waving around that "stable API Nonsense" document as
if it's a magic wand. Just because it's written down doesn't make it
right. And just because it has some advantages over another approach
doesn't mean the disadvantages aren't real.

Face it: most people won't or can't update their kernel on a whim. There
are lots of reasons for this. One reason is that, since there are no
stable driver APIs/ABIs, they might have the situation where they need an
out-of-tree driver that doesn't work on the new kernel. Another reason
might be that the new kernel has a bug in an existing driver. Another
reason might be that said new kernel has a completely new scheduler, or
some otherwise potentially disruptive change. And in a mission-critical
environment, these risks are unacceptable.

The kernel devs can wave their magic "stable api nonsense" document around
all they want, but it doesn't change the real world. There's a darn good
reason why other platforms have stable APIs or ABIs. And unlike, say,
Microsoft, the kernel devs can be more ruthless about culling deprecated
APIs; nobody says they have to keep a broken or sub-optimal api around for
ever. But the current approach makes life nearly impossible for
out-of-tree drivers, and having no out-of-tree drivers makes life very
difficult for everyone who doesn't want to live on the bleeding edge.

I'm sorry but YOU can run a just-released vanilla kernel on your
production computers; I have work to do.

As for how often I get hardware that doesn't work on an old kernel? It
happens all the time, actually. Linux drivers often lag the hardware
release. USB has made life somewhat easier since there are more devices
with standard drivers. But the reality is that third-party drivers work
on a pitifully small number of kernels, and new hardware comes out
constantly that requires new or updated drivers. Heck, sometimes it's as
simple as a busted PCI ID in a driver which would be enough to turn an
expensive server into a door-stop. Want to fix that driver? You need a
new kernel. Madness.

Stable API Nonsense nonsense

Posted Oct 14, 2006 1:14 UTC (Sat) by i3839 (guest, #31386) [Link] (8 responses)

The alternative to the stable API nonsense is backport hell. If you know anything better then please say so.

So you're basically saying that running a shiny new, potentially buggy driver for your new hardware is acceptable for your mission critical system? And you buy new hardware on a whim too? Doesn't like a mission critical setup to me. Face it: you can't run any new software on your mission critical system. If you get new hardware and a new setup, then you at least need to test that setup for quite a while before changing to it. You probably also run a 2.4 kernel as that's more stable. Only when you're in a situation where you need some newer features which don't exist in older kernels do you need to upgeade to something newer. Bu then you're screwed anyway, as you can't keep your trusted stability anyway.

On one hand you plead for out of tree drivers, on the other hand you say

"But the reality is that third-party drivers work on a pitifully small number of kernels".

Maybe the fact that they are out of tree is the reason why they are supported for such few kernel versions? And you say that instead of merging them with mainline the kernel should keep its API more stable? Somehow that seems the wrong way around.

Instead of getting the new kernel you can also backport the fix for the driver. Or anyone else. But backporting all fixes to all so called stable versions is way too much work, and gets messy after a while. The question is if all the effort spend in doing that can't be better spend on keeping the latest version more stable, or on writing new drivers. And who's going to do all that backporting work.

Also keep in mind that people are trying to improve the kernel, they aren't just fiddling with it just for the heck of it. You'd want all the bugfixes, and the new features you need. The new features you don't need you don't have to use, so they won't cause instability. Only thing left are general improvements which might cause instability in the short term. But if your kernel panics because of that or because of a bug in a new driver doesn't really matter, does it?

Stable API Nonsense nonsense

Posted Oct 14, 2006 22:31 UTC (Sat) by mrshiny (guest, #4266) [Link] (7 responses)

You misunderstand me. I said that third-party drivers work with a
pitifully small number of kernel versions, but this is not a complaint
about the drivers inasmuch as it's a complaint about the kernel. The
reason those drivers don't work with more kernels is not because people
don't want to backport the drivers; it's because the kernel keeps
changing. You shouldn't HAVE to backport drivers.

And your comment about "untested" drivers misses the mark; I could have
two totally tested drivers that have been in production for months or
years but can't be combined on one box because they are for different
versions of the kernel. And even if I'm not running a five-nines server,
downtime is still expensive. If I run my business on my computer, and I
need to add or replace some hardware component that needs a driver newer
than my box, upgrading the whole kernel is a risk. There may be no whim
involved; maybe the old hardware isn't available. A new kernel is
potentially FULL of new bugs, especially in the drivers. I face this
problem all the time with Fedora Core, because they track the upstream
kernel pretty closely, and I've had kernel updates screw my network card
lots of times. Now, this box isn't "mission critical", but thank God, or
else I'd be risking lots of money every time there was a security update
or something.

As for the kernel devs, I understand they are working hard to improve the
kernel. The kernel is a great piece of software. I understand that it's
hard work, the bleeding edge of computer science. But it's not as simple
as "Don't use the new features". If those new features are "new
filesystems" or "new video4Linux2 drivers", fine, they may not impact me.
But there are lots of ways new features in the core could impact me even
if I don't want to use them. And even if the new features are beneficial,
the problem is I have to update EVERY driver I have when I update the
kernel. So I don't get ONE component that's changed, I get lots.

I don't understand why people don't seem to get the whole risk aspect of
this. It's basic software engineering.

Don't get me wrong, the kernel developers are great developers. But they
have chosen a methodology that I disagree with. I'm a software developer
myself, and I understand the pain of maintaining old interfaces when you
have a newer, better one. I know that it's nice to throw away old code.
But when you're writing a piece of software as important as the kernel,
you have a LOT of people depending on you, and the no-stable-API approach
is hostile to third-party developers.

Stable API

Posted Oct 15, 2006 0:05 UTC (Sun) by i3839 (guest, #31386) [Link] (6 responses)

I understand your point. I'm afraid there isn't an easy solution for the problem. The kernel devs want to move along, so don't want to keep the internal API stable. Keeping both the old and new API alive at the same time is problematic too, that may be harder to get right than making the new one bugfree. Having a dev branch and a stable branch of the kernel won't solve your problems either, and that's not what you asked for anyway.

What is your main grudge, that you need to upgrade the whole kernel for new drivers, or that keeping out-of-tree drivers up to date is hard? Probably both, and a stable API would solve both, no wonder you'd like it. ;-)

Would the following solution suit you: A stable kernel version where only bugfixes and new drivers or contained functionality are added, and nothing else.

Any other ideas?

Stable API

Posted Oct 16, 2006 13:17 UTC (Mon) by mrshiny (guest, #4266) [Link] (5 responses)

What I would like to see is a return, in part, to the approach used in the 2.2 and 2.4 kernels, where the kernel API was considered stable for the lifetime of the kernel. An API could be deprecated, indicating that it should no longer be used. After some period of time the API would be removed. Obviously this approach was not perfect but at least it allowed for out-of-tree drivers. I think it should be easier to separate the kernel from the drivers. With the current approach there is no deprecation period, and no warning to out-of-tree driver maintainers, thus making out-of-tree drivers "self-flaggelation".

Other projects are able to provide stable APIs (and sometimes ABIs as well) for long-lived releases. This problem is more complex in the kernel but I feel it should still be a design goal. However the kernel devs disagree and claim that not maintaining a stable API lets them improve the kernel faster. I think that if a stable API was seen as a requirement, like a stable user-space API is, they would just find a solution like they always do. Nobody seems concerned that user-space has to be stable for ever, while drivers may have incompatible APIs from point-release to point-release. I'm sure some middle ground could be found, where APIs could be deprecated for some time period and then removed eventually. Whether or not we need a stable branch with no new features, I can't say. I know lots of people would like to see that, but that isn't strictly necessary for a stable driver API or ABI.

Stable API

Posted Oct 16, 2006 21:10 UTC (Mon) by i3839 (guest, #31386) [Link]

As you say, the kernel devs don't have a stable API high on their wishlist. So instead of trying the impossible and let all of them work the way you want, it's more realistic to do the work yourself (with similar minded people), and to keep a stable API branch, one way or the other.

Personally I think it's best to just get all out of tree drivers merged into mainline, no matter how obscure the driver, as that's what most kernel devs seem to want. Also unrealistic, I know. But if they can't handle the flood, then they might change their mind.

Stable API (nonsense)

Posted Oct 22, 2006 6:25 UTC (Sun) by HalfMoon (guest, #3211) [Link] (1 responses)

Other projects are able to provide stable APIs (and sometimes ABIs as well) for long-lived releases. This problem is more complex in the kernel but I feel it should still be a design goal. However the kernel devs disagree and claim that not maintaining a stable API lets them improve the kernel faster. I think that if a stable API was seen as a requirement, like a stable user-space API is, they would just find a solution like they always do.

The www.kernel.org kernel is however not a "long lived release". And the reason it isn't is specifically because that's a complex problem that few of the kernel developers are concerned with.

What they're concerned with is bug fixing, user mode stability, and working on more hardware. That basically precludes the silly model you're promoting: freeze design bugs in concrete, for years, and pile workaround on top of workaround until it becomes unmaintainable.

As has been said before: if you want a stable binary API, go ahead and commit to one. Yourself, and whichever friends join you. (Or perhaps I should say, whoever you can pay -- get to pay? -- you to provide one.)

You're talking like someone who's never actually had to maintain a large software stack with multiple "frozen" layers of interfaces. And where many of those layers were misdesigned, and incapable of functioning well in a number of increasingly important cases ... maybe because they integrate poorly, and will always do so until the interfaces change. Speaking as someone who has been in that boat, I have no sympathy for your whining. If it really bothers you, you have the source code in hand and can try to do a better job. Once you really get into it you'll find that your whines were misplaced.

Just get those drivers merged to the mainstream kernel, then they'll get evolved and updated with everything else. No worries, that way.

Stable API (nonsense)

Posted Oct 22, 2006 18:24 UTC (Sun) by mrshiny (guest, #4266) [Link]

For your information, I do develop software and have to deal with stable
APIs and ABIs. And I love how when kernel developers complain that
maintaining an API is hard, and thus they don't want to do it, it's not
called whining, but when I (and others) point out the harm this does to
users, it's called whining.

Stable API

Posted Oct 22, 2006 9:49 UTC (Sun) by Duncan (guest, #6647) [Link] (1 responses)

> What I would like to see is a return, in part,
> to the approach used in the 2.2 and 2.4 kernels,
> where the kernel API was considered stable for
> the lifetime of the kernel.

What you want, it would seem, is the continuing stable 2.6.16.* series
kernels. The stable series kernels have been continuing only for a time,
but that one has a volunteer to continue it for much longer --
indefinitely at this point. It's now a continuing stable kernel with only
fixes (and a few new drivers but nothing interfering with the old stuff
but fixes, is how I understand it) backported.

I'm sorry I don't remember who it was that volunteered, partly because I
like the challenge of sometimes breaking change and run the -rcs and
sometimes daily snapshots so 2.6.16 is ancient history for me, but I do
remember reading the articles on it right here on LWN, so go look it up if
long-time-stable is what you are after.

Otherwise, the feeling is that many of the mission critical folks will
normally be running a distribution catering to that and their supported
kernels anyway, not anything as raw as the mainstream vanilla stuff. For
those that aren't, well, if you don't already have a tested backup server
at /least/ /ready/ to bring up when your "mission critical" one breaks,
and are relying on swapping in new hardware without testing it for a good
30-days first, well, you're obviously not treating it as so mission
critical after all, and if you aren't, why should the kernel devs?

Duncan

Stable API

Posted Nov 1, 2006 17:47 UTC (Wed) by i3839 (guest, #31386) [Link]

It was Adrian Bunk, see:

http://lkml.org/lkml/2005/12/3/55
http://kerneltrap.org/node/7164

Quote of the week

Posted Oct 13, 2006 16:54 UTC (Fri) by job (guest, #670) [Link] (1 responses)

I'm not sure if running just one driver from a completely different kernel together with all your existing drivers from another kernel would be preferable. It's absolutely guaranteed to be an untested combination, and the odds that it'll work without problems is probably lower. I know I would prefer to just install the latest kernel and be done with it.

Quote of the week

Posted Oct 13, 2006 17:24 UTC (Fri) by mrshiny (guest, #4266) [Link]

The thing is, by virtue of a driver being out-of-tree, it's always an "untested combination". However, if there were a stable API, this would be less of an issue because the API would (try to) guarantee that a properly-written driver would continue to work. But anyway, with out-of-tree drivers the drivers would be more likely to work with old kernels than new ones, by virtue of the old kernel having been around longer for testing by the driver writer.

Quote of the week

Posted Oct 12, 2006 18:44 UTC (Thu) by bronson (subscriber, #4806) [Link]

khim... You're joking, right?

Quote of the week

Posted Oct 19, 2006 17:25 UTC (Thu) by cbcbcb (subscriber, #10350) [Link]

> Then you go and grab "upstream kernel"

... and an "upstream udev" (although recently this seems to have stopped being necessary)

Next, you need to decide whether you need any of the new CONFIG options. If you're smart you'll use make oldconfig, but that won't help when you get asked if you want, for example, DMA engine support. (My hard disk etc uses DMA, but is this a new option for that code, or new code for some new device I don't have?)

What happens when ipchains compatibility is removed from Netfilter? I'll have to rewrite my firewall rules, and that is a big deal.

I also need 10's of megabytes of development tools if I haven't installed them already.

Quote of the week

Posted Oct 12, 2006 10:14 UTC (Thu) by shapr (subscriber, #9077) [Link] (3 responses)

Long ago and far away DOS drivers were the standard and you had to check carefully to see if a piece of hardware would work with Windows 3.1

At some point Windows became popular enough that DOS drivers were rare.

Until hardware sold on the shelves commonly comes with a penguin compatibility logo, it'll be simpler to check for Linux support ahead of time.

C'mon, you know that your make, model, and year of car doesn't have much compatibility even with other years, why would you expect the Windows monoculture to try to be compatible with Linux?

You want a driver that works for "real people"
meaning
you want to be able to walk into a store and buy hardware without having to surf the web to see if it has a Linux driver.

The solution is simple, go ahead and buy the hardware. If it's not supported in Linux, call the company who makes it and complain that they're not supporting your OS of choice, and that the drivers would be written for them if they'd release sufficient specs and docs.

Then take that hardware back and buy that same flavor of device from another company. Repeat until you're happy with the situation.

Windows drivers became common because customers complained to the companies that made the hardware.

Quote of the week

Posted Oct 13, 2006 16:58 UTC (Fri) by job (guest, #670) [Link] (2 responses)

I was actually in a store shopping for a new printer the other day. One model on a shelf had a proud penguin sticker just beside the Works-with-Windows one. I think it was a Samsung. So we're actually closing in on your vision. It made my day anyway...

Quote of the week

Posted Oct 15, 2006 12:04 UTC (Sun) by tlw (guest, #31237) [Link] (1 responses)

> One model on the shelf had a proud penguin sticker
> just beside the Works-with-Windows one.

Unfortunately it looks like I'm going to have to un-make your day. :-)

First of all there is no governing body (that I am aware of) which tracks the use of any such "works-with-linux" logos or statements. Vendors are therefore free to make any such claim and slap as many penguin logos on a product without any sort of outside confirmation, testing, or clarification.

In order to put a "works-with-windows" logo or statement on a product, the vendor must download a huge test-bench application, run it, and submit the results to Microsoft. This suite attempts to test the device in many different situations such as high-load, and different sleep states. There are different tests for video cards, printers, hard-drives, and so on. Only after the results have been confirmed can a company make any such claim. Obviously this system has many flaws too, but for some people is slighly more reassuring than taking the vendor's word; the vendor is in a conflict of interest here.

Secondly, just because the vendor claims a product works with Linux does not mean it works with your Linux setup or the one you intend to use with their product. It just means the vendor allegedly got this product to work with whatever version of Linux they had floating around the shop internally.

Have you actually ever bought a product with a penguin logo thinking that it would work on your Linux setup? Don't be surprised if you should open the packaging and find a little slip of paper that says in order to make this device work on Linux you have to compile an out-of-tree module found on the CD yourself. Oh yea, the module was written against 2.4.15, and the driver code is just a wrapper which loads a binary blob... and that's if you're lucky. Sometimes all you get is a URL to an un-named IP address where you'll find a binary module quietly whispering "install me, I dare you, I promise I won't do anything naughty".

But hey, they got it working with 2.4.15 so they put a penguin on the box. Good luck getting it to work with the SMP system you bought last week running the latest Linux kernel!

Putting a penguin on a box means nothing because nobody's regulating it. The presence of the penguin has no implied legal meaning or promise. It can mean everything from "there is an in-kernel open-source driver which is actively maintained for this product" to "we haven't even bothered to see if it works with any known flavour of Linux". It's true! If some bean-counter told the vendor they could improve sales 10% by putting a penguin logo on the box the vendor's first question is: "How much does it cost to put that logo on the box?". The answer would be: "Nothing. There are no test suites to pass, no governing body to pay dues to, and no legally implied meaning." How many sleepness nights do you think the vendor will endure?

Who knows, maybe some day the penguin logo on vendor's boxes will become such a sham the Linux community will be forced to regulate it in order to head-off the negative publicity generated by hundreds of vendors shamelessly slapping penguin logos on anything they sell and the resulting disappointed Mom&Pop Linux users suddenly finding themselves with a product they've paid lots of money for but can't get working until they figure out how to compile and load a kernel module.

Works with Linux sticker

Posted Oct 21, 2006 11:53 UTC (Sat) by anton (subscriber, #25547) [Link]

In this concrete case this most likely means that the printer supports Postscript, no special kernel or CUPS drivers needed.

Quote of the week

Posted Oct 12, 2006 12:09 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

More to the point, what happens if an out-of-tree driver isn't mergeable and won't likley ever be merged?

There are many legitimate reasons for this; including many cases where "just use a new kernel" is NOT an option.

One driver I maintain currently has to work with everything from 2.4.0 through 2.6.18.

Quote of the week

Posted Oct 12, 2006 13:18 UTC (Thu) by ebiederm (subscriber, #35028) [Link] (2 responses)

Well if a driver isn't mergeable the most likely reason is the code quality is such that it should not be run anyway.

In most cases backports can be handled by a simple compat_mac.h that defines the new apis on top of the old kernel.

Even if you have to maintain the backports merging a driver into the new kernels is a good idea so other developers can see what kind of things your driver relies on, so they don't remove the functionality you depend on.

This also makes it easier for new users to get your driver as after a point the driver is available in the kernels all of the distros ship and you don't have to do anything.

Beyond that David's comment about flagellation is apt. You may choose to do it but the price you pay for not working with the other developers is that they don't work with you.

Quote of the week

Posted Oct 12, 2006 14:29 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

No; it's not mergeable because it is structurally considerably different from the HolyWayOfLinux, and to make it AcceptableForMerging would strip away most of the reasons for using it (rich userspace configuration API), not to mention a great deal of work for little apparent gain.

Meanwhile, I don't think the kernel people go out of their way to make out-of-tree drivers difficult to maintain ("don't care one way or another" is a good way of putting it), but dismissing all out-of-tree drivers as somehow inferior, unsuitable for use, or "self-flagellating at best" is grossly unfair, for the precise reasons that Linus mentioned:

> it's the damn drivers maintained outside the tree, and
> people who want to maintain the same driver for multiple different
> versions of the kernel.

If your driver needs to support multiple kernel versions, then you need to maintain it out of tree, whether or not there is an in-tree variant to keep track of as well.

While there is an extensive compatibility header already in place, there are still many bits and pieces littered all over the codebase for things that are simply incompatible. Even within the 2.6-series, for example, pcmcia changed radically for both 2.6.16 and 2.6.17.

Quote of the week

Posted Oct 12, 2006 18:34 UTC (Thu) by Thalience (subscriber, #4217) [Link]

I think "self-flagellating" was meant to describe the self-inflicted pain of maintaining the driver out-of-tree, and not using it.

Quote of the week

Posted Oct 12, 2006 13:15 UTC (Thu) by dougg (guest, #1894) [Link] (7 responses)

David seems to forget that there are thousands of open source drivers "out of tree" because their authors don't have the political clout to get them in, the management thinks they are too obscure, or the management doesn't like them. In the latter group are my favourites: the drivers that bypass the management. A practical consideration is the size of the kernel source tarball: how big is too big?

So why make it difficult for these "out of tree" drivers just to spite some recalcitrant hardware vendors?

Quote of the week

Posted Oct 12, 2006 13:40 UTC (Thu) by ebiederm (subscriber, #35028) [Link] (3 responses)

Beyond the obvious: Documentation/stable_api_nonsense.txt

The reason for this change is that this api became very difficult to support on one of the architectures, and that architecture is in tree. In tree code is more important that out of tree code. Plus the argument was unused.

As for the kernel tarball size the last anyone checked it is growing linearly and hard drives are growing exponentially so unless relatively the kernel is getting smaller. Having a driver in tree is actuall less code because you don't need the backwards compatibility cruft so for people needing to maintain things an in tree driver is actually less code and less work because they don't have to search for the driver and the driver they have to read is smaller.

Beyond which people really did work out strategies to keep drivers working on older kernels.

As for political clout to get a driver in, in most cases all it takes is a little bravery. Adding a totally new class of driver is harder but only because it takes new infrastructure and the new infrastructure needs to be discussed.

My favorite suggestion was:
#ifndef __PT_REGS
# define __PT_REGS , struct pt_regs *pt_regs
#endif

Which makes it trivial to maintain source compatibility on old kernels.

Quote of the week

Posted Oct 12, 2006 16:47 UTC (Thu) by william.waddington (subscriber, #25316) [Link]

#ifndef __PT_REGS
# define __PT_REGS , struct pt_regs *pt_regs
#endif

Works for me, but I haven't seen the matching #define __PT_REGS <nothing> in the kernel tree/patches yet. Likely to be forthcoming/already there somewhere, or do I need to work up the nerve to submit a patch?

Quote of the week

Posted Oct 15, 2006 13:17 UTC (Sun) by tlw (guest, #31237) [Link] (1 responses)

> As for political clout to get a driver in, in most cases all it takes is a little bravery.

Either you are making one of the funniest Linux-related jokes I've ever heard, or you are conveniently ignoring and sugar-coating the hundreds of flame wars that take place regularly on LKML.

If it were simply a matter of changing an identifier here and moving a comma there I could agree with you. But in most cases trying to submit a driver results in a difference of opinion regarding the design of the submitted code; and the only way to win a design discussion is with large amounts of clout.

Is there an empirical way to absolutely prove one design is better than another? Absolutely not. Design decisions are always a matter of personal taste: some designs solve some problems better and other designs solve other problems better. Additionally, when you consider that all these "design discussions (now I'm sugar-coating!)" are done out in the open on mailing lists that are backed-up for all eternity on millions of hard disks around the planet and taking into consideration the large number of these discussions which degenerate into flame wars and name calling (sprinkled with explicatives, to taste)... well, let's just say that takes a whole lot of "bravery". :-)

If you want to test my theory please email Linus, CC'ing LKML, and try explaining to him that the Hurd kernel is a much better design than his monolithic kernel. Or email LKML explaining that you've reviewed the design of the ReiserFS and found it better than ext3. Or email GregKH (CC:LKML) informing him that devfs is better than sysfs and therefore it should not be removed from the kernel because you want to continue using it. Just because they say their designs are better doesn't mean they're better for you.

Quote of the week

Posted Oct 16, 2006 10:01 UTC (Mon) by dwmw2 (subscriber, #2063) [Link]

If it were simply a matter of changing an identifier here and moving a comma there I could agree with you. But in most cases trying to submit a driver results in a difference of opinion regarding the design of the submitted code; and the only way to win a design discussion is with large amounts of clout.

No. The way to win a design discussion is with a good design. And thats why your examples about Hurd, Reiserfs and devfs are so clearly bogus.

Youre right that there is a large element of personal taste involved. But unless a design is actually bad you wont normally be held ransom to others taste if you can justify your own.

One of the good things about Linux development is that it goes largely on the merit of the code, and political clout plays a relatively small part in it.

Quote of the week

Posted Oct 12, 2006 16:41 UTC (Thu) by william.waddington (subscriber, #25316) [Link] (2 responses)

We have included source with our drivers going back to SunOS 4.1.3 - about the time Linus was coding in his jammies. To the extent possible, we try to protect our users/OEMs from kernel changes, and give them a consistent API. Part of this is a (reasonable) expectation that they can download our latest 2.6 driver (for example) and expect it to play nice with the latest 2.6 kernel as well as earlier kernels in the 2.6 series.

The niche is small, and the drivers of interest only to us and a small group of users and OEMs. The chance of main line inclusion is zero (or maybe a large negative number) due to niche size, and probably coding style...

I wouldn't expect kernel developers to constrain changes for the sake of out-of-tree maintainers, but where simple #define(s) in the kernel tree can help us maintain source-level compatibility (our drivers are intended to be compiled by the user/OEM at initial install) it would be quite helpful.

Quote of the week

Posted Oct 12, 2006 19:11 UTC (Thu) by net_bh (guest, #28735) [Link] (1 responses)

>The niche is small, and the drivers of interest only to us and a small group >of users and OEMs. The chance of main line inclusion is zero (or maybe a >large negative number) due to niche size, and probably coding style...

For this reason alone, please read Greg-KH's OLS keynote @ http://www.kroah.com/log/linux/ols_2006_keynote.html
Somewhere in the middle he talks about exactly your case and why it is still beneficial to push your code in-tree.

Quote of the week

Posted Oct 13, 2006 14:13 UTC (Fri) by william.waddington (subscriber, #25316) [Link]

"For this reason alone, please read Greg-KH's OLS keynote @ http://www.kroah.com/log/linux/ols_2006_keynote.html
Somewhere in the middle he talks about exactly your case and why it is still "beneficial to push your code in-tree."

You mean that pushing my code in tree would improve my coding style? No doubt :) Seriously, I'm familiar with Mr. KH's presentation, and I don't really disagree, at least for new driver development.

Even so, there are things about the code that would make pushing in-line a real ordeal: coding style, plethora of ioctls, and DMA directly to/from user buffers, among others. The coding style is fixable, and there are probably "better" ways to handle the API, but "fixing" the API would require abandoning the read/write/ioctl interface we have kept consistent for multiple unixen for 15 years - which seems to be working well for our OEMs and end users.

Stable API

Posted Oct 19, 2006 7:21 UTC (Thu) by lmartelli (subscriber, #11755) [Link] (1 responses)

You favorite distribution is 4 month old. You buy new hardware with brand new network card whose driver wasn't included in you distro's kernel (the network card did not exist at that time). Even if there's an in tree driver in the latest kernel (which your distro does not have yet), you're stuck because you won't be able to download it.

Stable API

Posted Oct 22, 2006 10:21 UTC (Sun) by Duncan (guest, #6647) [Link]

Here, let me fix the scenario for you:

You favorite distribution is 4 month old. You [look at buying] new
hardware with [a] brand new network card whose driver wasn't included in
you distro's kernel (the network card did not exist at that time)[, but
you realize that fact, and look for something that will work for you
because you've verified it's supported, perhaps a bit older hardware].
Even if there's an in tree driver in the latest kernel (which your distro
does not have yet) [for the new hardware you passed over], you [are not]
stuck because you [did the research and know your kernel supports the
hardware you /did/ choose, well].

Linux doesn't have the market share of that unfree OS. It's a hard fact
at this time (tho not so much in the server space) altho things are
gradually changing. Part of adjusting to live with that is either
learning to do your research, picking carefully what you buy, or living
with the consequences for failing to do so. Of course, one possible
chosen consequence would be simply caving in and going back to that unfree
OS, and not having to worry about it, but losing all the other things you
chose freedomware/Linux for (including freedom from the various driver
bugs plaguing the closed source world, that aren't a priority for the
manufacturer to fix as they've moved on, and are extremely difficult for
anyone else to fix as they don't have the code).

Once you recognize that and do the research /before/ you buy, buying with
the results of that research in mind, things are MUCH easier. Take it
from someone who was actually doing that research for all his hardware
from two years before certain eXPrivacy and remote-root-priv policies of
that unfree OS finally forced him to make the jump. I was prepared for
it, and everything "just worked" when I switched, at least once I figured
out how freedomware/Linux worked with it in general, because I hadn't been
buying anything that wouldn't work with freedomware/Linux for two years.

Duncan

Quote of the week

Posted Oct 19, 2006 15:59 UTC (Thu) by quintesse (guest, #14569) [Link] (3 responses)

Although I understand the reasons behind stable_api_nonsense.txt and can't disagree with it I also understand the other side of all this.

Yes, the best thing would be to have all drivers in the kernel but there are times when that just isn't possible. An example given above was a driver that is built in such a way that it would never be accepted.

The kernel devs might have some very good reasons to disapprove of such a driver in the kernel. But on the other hand there might be very good reasons for some users to do things differently. And the source being freely available makes all this possible of course, but it might be quite difficult at times.

Of course, it's the kernels devs that are spending the time so they are calling the shots.

At times I´ve wondered if it wouldn't be possible for others to make a stable "Device Driver API" that interfaces to the kernel. Drivers would be written for to that API and it would be the responsibility of the API devs to make things work with each kernel. It might not be possible to maintain this API a 100% for very long periods of time, but the fact that for several years I could recompile a driver for a video capture card without having to make any changes to the code seems to suggest that at least it should be possible to make a semi-stable API.

Of course it that were easy to do (or even possible) it would already exist, right?

Ok, I'll continue dreaming now ;-)

Quote of the week

Posted Oct 20, 2006 14:58 UTC (Fri) by sobdk (guest, #38278) [Link] (2 responses)

Of course it is possible, and not all that difficult. It is called an abstraction layer, and this really is a common method for maintaining out of tree drivers. Ever wonder why you have to compile something when you install that evil binary video driver?

The fact is maintaining an out of tree driver isn't all that hard, but manufacturers are lazy. They want to write a driver once, and never touch it again. If this is what they want then write it once, and put it in the kernel. More than likely it will take them 3 kernel releases to get their driver finished in the first place so when they release their hardware they can have an out of tree driver that supports about 3 versions back, and an in tree version.

Quote of the week

Posted Oct 20, 2006 17:29 UTC (Fri) by william.waddington (subscriber, #25316) [Link] (1 responses)

_Some_ manufacturers may be lazy. We, on the other hand, are industrious (and trustworthy, loyal, helpful, friendly, courteous, kind...).

No particular problem keeping our drivers current. The problem arises because some users want drivers for the latest kernel, while others are using/will use/want to use older (more stable in their minds) kernels.

If the DKI changes without including compatiblity hooks or "automatic" build options (like the #define above), the user is confronted with a page full of driver versions, and often picks the wrong one.

It's much simpler if the user can just download the latest driver for a given major kernel version and have that work on all kernels up to the latest.

Quote of the week

Posted Oct 21, 2006 12:17 UTC (Sat) by anton (subscriber, #25547) [Link]

If the DKI changes without including compatiblity hooks or "automatic" build options (like the #define above), the user is confronted with a page full of driver versions, and often picks the wrong one.

The perfctr patch has a nice automatic way of dealing with this problem.

Which reminds me that that patch has been submitted for in-kernel inclusion once, and apparently was not accepted (I have not followed the discussion on the reasons, but my impression was that the author did restructure his code to make it more acceptable to the kernel folk.