Slashdot Mirror
Novell Delivers Device Driver Breakthrough
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."
http://developer.novell.com/wiki/index.php/FAQ_for _the_Partner_Linux_Driver_Process
This "breakthrough" requires device vendors to recompile (and possibly port) their driver for every distro, every time that distro updates their kernel ABI. The only thing that has really changed seems to be that Novell will keep track of when the kernel ABI changes and notify driver developers.
This doesn't have anything to do with that recent NV/ATI GPL violation story, does it?
(after reading Novell's intro page and the FAQ) 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.
I am a longtime SuSE Linux Professional user, and I always wondered why they change the externally-visible kernel version number for each security update.
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)
No even an asbstation layer, they are just syncronising driver updates and kernel updates.
Ahhh... the click through link gives alot more details. http://developer.novell.com/wiki/index.php/Categor y:Partner_Linux_Driver_Process
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...
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.
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...
I am TheRaven on Soylent News
--
Given enough personal experience, all stereotypes are shallow.
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.
I have games (HL2, UT2k4, Q4, EVE, etc) and XGL (transset over xcompmgr) with fully compatible nvidia binary drivers and every bit of hardware on my computer supported, nearly, all under gpl
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.
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
Editor, A1-AAA AmeriCaptions
Ok, I'll bite, because I figure that you're young enough to not know how google works. ndiswrapper should take care of your network cards. as for the printer, look here. Oh, and do make sure you never buy any new piece of hardware until the company which makes it at *least* releases working binary drivers. That should help move things along rather nicely. Also, before mods mod me down as offtopic... This here's a real-world luser with a real-world problem. He's stuck between a GoodThing(tm) (the linux driver dev process) and a BadThing(tm) (crappy hardware companies who think they've something to hide), with nowhere to go.
Something bad is coming when people are suddenly anxious to tell the truth.
Sounds like dkms from Dell:
when you see the word 'Linux', drink!