User: Password:
|
|
Subscribe / Log in / New account

KS2008: When should drivers be merged?

KS2008: When should drivers be merged?

Posted Sep 16, 2008 15:13 UTC (Tue) by sbergman27 (guest, #10767)
Parent article: KS2008: When should drivers be merged?

"""
Greg will take responsibility for getting some of those linux-staging drivers into the mainline; he has, it was suggested, just become the official crap maintainer.
"""

One common complaint about Linux is its lack of support for newer hardware. Never mind that it supports every ISA card ever sold. What people care about is the new stuff that they can buy *now*. It seems to me that the kernel devs consider new drivers, and by extension, the skills of the programmers writing them, to be crap. I'm not sure that attitude will be good for Linux in the long term.

But determining to try to get the stuff into the mainline tree is a positive action, regardless.


(Log in to post comments)

New drivers

Posted Sep 16, 2008 15:26 UTC (Tue) by corbet (editor, #1) [Link]

I don't think I wrote anything to give that impression. There is no such general feeling. It is true, though, that some new drivers are poorly written. That's what the discussion was about; nobody worries about the well-written drivers, dozens of which go into every kernel release.

KS2008: When should drivers be merged?

Posted Sep 16, 2008 19:31 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Most in-house stuff is crap. Never designed to be looked at by the general public, still less criticised by dozens of expert kernel developers. It is very noticeable, for example, that an in-house program which I got cleared to be released as GPL, is still sat there waiting for me to take action because I realised after getting the OK to release it that it needs at least a couple of days of extra work doing to it before outsiders will be able to use it sensibly. It mistakenly relies on an extension to a standard that it implements, and (a colleague pointed out when I enquired) nobody except us implements that extension. Whoops. From any outsider's point of that program is currently crap, so I won't be releasing it until it's not crap.

Developing the drivers for yet another brand of 100Mbit network card is not most people's dream job, so it should be no surprise that the developers working for a lot of hardware outfits are not the best in the business. That doesn't mean that /they/ are crap, but it does mean that their code isn't necessarily going to be up to the standard people expect from Linux.

Old in-house drivers weren't any better, I've seen the code that made the Video Toaster go. It's awful, you'd never have guessed that the Video Toaster was a roaring success if you tried to judge based on the quality of source code.

But actually today's drivers have even more opportunities to be terrible than did those from the Video Toaster era. You can screw up suspend and resume, you can fail when there are multiple CPU cores, there are countless novel ways to screw up. Microsoft has a QA process for new drivers, which must be passed before they'll certify the drivers for use with ordinary Windows PCs. Perhaps their QA process doesn't use the word "crap" but the judgement is the same, "this driver isn't good enough, try harder next time".

KS2008: When should drivers be merged?

Posted Sep 19, 2008 23:43 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Much of the crappiness being referred to here is not general crappiness that you might get from an incompetent or rushed engineer -- its just failure to conform to standards of the Linux kernel. It could be a different coding style. It could be stuff that was designed to meet requirements unrelated to the requirements of mainline kernels (e.g. the code was ported from Windows). It could be code that doesn't work in some of the myriad scenarios it might find itself in, in which it was never needed to work before.

KS2008: When should drivers be merged?

Posted Sep 17, 2008 17:10 UTC (Wed) by iabervon (subscriber, #722) [Link]

There's the sort of fundamental problem that vendors don't want to announce unreleased hardware, let alone publish drivers for it, and then they obsolete the hardware sooner than the latency in keeping a kernel release into users' hands. They're doing their release cycle based on the idea that they'll ship drivers, which they write internally and which don't have to be maintainable (i.e., only have to work with one or two already-released OS versions), with their hardware.

The solution is probably for them to design hardware that functions okay with drivers that aren't specifically for that hardware release, such that Linux users get hardware that works fine today and performs better over time (as newer drivers notice more hardware features and use them).

KS2008: When should drivers be merged?

Posted Sep 17, 2008 19:53 UTC (Wed) by michaeljt (subscriber, #39183) [Link]

Perhaps this would be a case to ship the vendor's drivers "until something better is available", probably disabled by default in the main kernel tree. Or alternatively, to have a private mailing list with relevant kernel drivers that they can submit to, so that their code will not be made public before they are ready.

KS2008: When should drivers be merged?

Posted Sep 17, 2008 22:16 UTC (Wed) by iabervon (subscriber, #722) [Link]

Releasing vendor drivers wouldn't really help much, since it's pretty late by the time users get anything released by the kernel team. Getting drivers for pre-release hardware to kernel reviewers under NDA could be a big help, though, particularly if that included distro representatives who could get a package for the module through QA and ready to release simultaneously with the hardware. I wonder if big hardware vendors would be interested in the linux driver project that Greg KH runs, for the express purpose of collecting acks from reviewers (and, of course, comments, but those would presumably be uninteresting before they could be posted) in advance of the code going out to the world.

KS2008: When should drivers be merged?

Posted Sep 19, 2008 1:27 UTC (Fri) by njs (guest, #40338) [Link]

IIRC it's common for (clueful) vendors to provide docs under NDA with the actual release embargoed until the hardware is announced. Or there are weird tricks, like drivers landing in the mainline kernel under code names, and then when the press release goes out so does the rename-all-the-symbols-in-that-driver patch.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds