Novell Delivers Device Driver Breakthrough 241
An anonymous reader writes "Novell today announced a new Linux device driver process to make it easier for third party device driver writers to integrate their drivers with SUSE Linux." From the article: "The new driver process allows customers to obtain drivers independently of Novell® kernel updates and supplies a straightforward approach third parties can use when developing device drivers for Novell's SUSE® Linux Enterprise products. The new Linux driver process developed by Novell allows hardware and software vendors to provide Linux drivers and driver updates for their products to customers directly and transparently, in a way that is completely integrated with SUSE Linux Enterprise delivery and support."
oups! (Score:5, Informative)
Something is breaking, that's for sure (Score:5, Informative)
Shim driver? (Score:3, Informative)
This doesn't have anything to do with that recent NV/ATI GPL violation story [slashdot.org], does it?
(after reading Novell's intro page [novell.com] and the FAQ [novell.com]) It's not a shim driver: "A driver is linked to a specific kernel version via Kernel Application Binary Interface (kABI) metadata. ... In the event of kernel updates Novell will notify partners about possible changes to the kABI". This is just a new process by which established device manufacturers can work with Novell, not a shim driver to create a stable kernel ABI.
Version numbering (Score:5, Informative)
This makes binary and externally compiled drivers (including nvidia and vmware drivers that I use) break on every kernel update, and probably unnecessarily, The chances that anything changes to the driver interface because of a security patch are probably very slim, and they could always change the version in case a major change is made.
But now, it is just an annoyance. I need to install their patch, reboot into textmode, re-make the vmware and nvidia drivers, and again reboot to go back to fully functional operation. And I know how to do this. A beginning user is happy to finally have such an install/compile procedure behind him, and not at all happy to see the whole thing break after YOU installed a kernel patch.
(not to mention the fact that it can take him quite some time to find out that the kernel patch is the reason, and how to fix it)
Re:Marketing blurb (Score:5, Informative)
Re:Marketing blurb (Score:5, Informative)
So basically they are setting up a method for vendors to submit driver updates through them, then distributing them with YaST if the versions dont match.
Again, not seeing the breakthrough...
Re:Version numbering (Score:3, Informative)
Unfortunately this is because the ABI _could_ change on every recompile. Hence the kernel version number has to be changed to reflect the fact that some drivers might be incompatible.
Re:Overhead? (Score:3, Informative)
None. There isn't an abstraction layer. This is just a new process for Novell to notify hardware makers when they patch or build a new kernel, get precompiled binary drivers for their newly-built kernel and make them available to users as part of the security-update download of a new kernel package. It's got nothing to do with the actual driver modules, kernel compilation or anything in the software itself.
Re:Breakthrough? (Score:3, Informative)
To move this to the software realm, where I suspect people here are more comfortable, this is like saying that 'if we release the headers for our library, then it is easy for people to duplicate the library.' Tell this to the WINE guys, who have had the headers (and documentation) for the Win32 API for over a decade. Effectively they are saying that the interface is a significant portion of the design. Personally, I would hope that the implementation would be an order of magnitude more complicated than the interface...
Re:Version numbering (Score:3, Informative)
1. init 1
2. install driver
3. init 5
(or, instead of init, telinit. It's the "correct" way)
BTW, if you can install the drivers without human intervention (in nvidia case, you need to extract the files from the package first), put something like this in
modprobe -q module || script_to_install_driver
Re:Oligopoly (Score:3, Informative)
A bit unfair... (Score:3, Informative)
Of course this benefits Novell. They have a business to run. But just because you're upset another distro might not benefit from this, it's rather unfair to say that SUSE isn't "real" Linux, isn't it? Aside from proprietary drivers (and there aren't many - I'm not using any in my case), all source is included in the distribution.
Re:No need for competition... (Score:3, Informative)
Almost nothing you just mentioned is under the gpl. The only thing that is free is XGL, and that semi-entails that you have a non-gpl video driver.
Re:Failure of computing. (Score:5, Informative)
Yes. It does.
Like it or not, the underlying hardware for computer peripherals -- be they USB cameras, joysticks, mice, SCSI controllers, graphics cards -- can be substantially similar, or completely different, most often because they take completely different approaches to solving the same set of problems.
A splendid example -- and one I can speak to directly, having written several drivers for them in my time -- are graphics cards. Once upon a time, all a graphics card did was display pixels. It was a dumb framebuffer, and the CPU did all the drawing. But even that much wasn't uniform across all cards. Some displayed only monochrome. Others displayed two or four colors per pixel. Sometimes the colors were hard-coded. Other times the colors could be defined by the user and stored in a palette (which could be 6, 8, 9, 12, 15, 18, 21, or 24 bits wide). Some had the pixels arranged as a linear array in memory; others stored pixels in an odd pattern based on a logical transform of the X and Y coordinates. Which line draw or rectfill routine you used depended on which card was installed.
Then someone invented a chunk of hardware called a "blitter" which did some of the drawing operations for you. All your old code would work, since it could still write to the framebuffer pixels, but the blitter was faster. But wait! Some blitters used X and Y coordinates and dimensions. Other blitters took memory addresses and byte counts. Some wanted you to write values to in-chip registers to setup and perform the blits. Others preferred you wrote a series of instructions in RAM and told the chip where the instructions were. All would do straight copies, but some would also do logical operations on the pixels (AND, OR, XOR). But not to worry; the device drivers abstracted all this away. All you had to do was call the rectFill() routine; the driver would worry about the gory details.
And that might have been the end of it, except this jerk named John Carmack wrote a game called Quake, and suddenly just 2D hardware support isn't good enough for anyone anymore :-). Enter 3Dfx, ATI, Rendition, NVidia, and others, each with their own approach to draw 3D primitives quickly, each requiring custom software that knows where all the HW registers are, what they mean, and how to manipulate them.
All of which is a long-winded way of saying: The abstract interface at the application level may be the same (rectFill(), glVert3f()), but the actual nuts and bolts of turning that abstract expression into pixels on the screen varies enormously.
You're not completely off-base, though. There are some very simple peripherals where the abstractions have been pushed directly to the hardware layer (keyboards, mice, USB HID devices), but even this is an arguable point, as the firmware running in the peripheral itself is simply translating what's really going on into the commonly-accepted abstraction. Nowhere was this more true than when mice transitioned from opto-mechanical (rolling balls and encoder wheels) to purely optical (tiny cameras). Internally, they're entirely different, but the firmware running inside completely obscures that fact, and all you see on the wire are movement deltas.
So, no, I'm not involved in an elaborate conspiracy to justify my job. As long as silicon designers have new and evolving ideas about how to make things better/faster/cheaper, device drivers will remain a necessity.
Schwab
Re:Does this mean Linux will work? (Score:1, Informative)
DKMS From Dell (Score:3, Informative)
Sounds like dkms from Dell: