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."
Plan 9 offers everything you would expect from a modern desktop OS. So there is no need for Suse Linux.
... it is generally the result of a badly written 3rd party device driver, and the inability of the OS to protect itself from that driver. Have Novell delivered a major breakthrough here (as the article suggests) or the beginnings of a major headache?
I know there will be replies about how the architechure of Linux protects us from some of the risk, but in reality 3rd parties will circumvent any device driver model in an effort to make their device perform optmally, even at the expense of the wider platform.
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.
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...
Well I hope it is! The last thing we need is a whole bunch of obscure binary blobs running in kernel mode!
http://outcampaign.org/
This is only going to work if you're using SuSE. And if you don't compile your own kernel. It only gives vendors an excuse to call their shitty binary-only drivers "Linux support". I'd call this thing a Linux driver setback.
This argument is repeated time and again here on Slashdot and the fact is it is rediculous. Want to know why? Because Novell's customers want it. In fact, they want Suse Linux to run on whatever white-box thrown-together-component list they decide, and having vendors supply drivers to reach that goal makes Novell a more attractive company.
Novell isn't /. - this is the real world. Compatability = greater acceptance = better marketing position & happier customers = more sales. Period.
Excuse my speling.
Making The Bar Project
Sounds more like a new marketing process.
"I now inform you that you are too far from reality."
i hope you burn in hell for writing closed source drivers.
... this isn't 1998 anymore, I understand the need for open source drivers so you can troubleshoot issues with both them and the kernel but, come on now, grow up - either figure out a way to make it so binary only drivers aren't a problem with stability, make a certification process, or forever be stuck with having 1/3rd the devices supported, 1/3rd supported poorly, and 1/3rd oblivious to your existence.
Sad thing is, this probably isn't a troll. You sound like most of the kernel developers who refuse to make a stable API or ABI.
You wonder why Linux has such shitty support? Your attitude and the attitude of the devs
From the point of view of your average home desktop user, being able to install any 3rd-party driver with a single click (and a uniform installation process!) and then automatically track the updates to all installed drivers whenever kernel is updated is a breakthrough. For developers, it means that they no longer have to wait for the distributor to package the driver for YaST - they can do it themselves, retaining more control over how things work.
It just pisses me off how Novell might be very successful in this, and if they are, it has no benefit for Linux (as in, you know, the free/open source side), and quite possibly a negative effect. All this does is benefit Novell, and once companies write up their drivers, where are the rest of us that use real Linux left? In the dust, and possibly moreso, because now the companies can say with a smile on their faces that they support Linux, and may not ever bother to turn back and support the rest of us. Thanks Novell, for giving the world a stabler Windows.
First off, Novell's distribution of Linux is "real Linux." I'm not sure how you think Debian or Ubuntu or whatever is "real Linux" but somehow SuSE, which runs the same kernel, programs, etc., is not. It's foolishness.
Secondarily, if you're trying to crucify Novell for attempting to make it easier for ISV's to integrate with their software offering, I have no idea how you plan to defend that. The problem with Linux acceptance is EXACTLY the problem of standardization. And since there seems to be no standards in motion for how ISV's should write and deploy Linux device drivers, they started their own.
What's the alternative to this? From past experience I think we can agree it's either (a) Hope that someone, somewhere comes up with a standard for "all Linux device driver development and deployment" and then hope that EVERY major Linux vendor and packager adopts this standard implementation and process. This is EXTREMELY unlikely and would take ages AND will still leave out some of the thousands of "distributions" on distrowatch and other places. Boo hoo, it's not fair! (b) Continue as we have been where device drivers are implemented in a myriad of different ways by different ISV's and have little to no support from the vendors themselves and NO support from the distribution creator.
Both of these options suck.
At least the Novell initiative here makes some promises and puts some manpower on these issues. Even the promise of Novell WORKING WITH VENDORS at all is such a welcome change from, for example, the crap shoot that is installing ISV device drivers with a Debian-like Linux system. I'm not saying it doesn't work sometimes or that Debian is a bad distro... but try to get support from ISV's for device drivers they wrote on, say, Ubuntu and let me know how that goes.
This is only a new process for Novell to deal with vendors to make kernel upgrades more seamless to customers. I don't think this is going to cause all the vendors to release binary only drivers, but for the ones who do, SUSE will now work better with kernel updates. Personally, every system I use has an nvidia card in it and a marvell sata controller which only has a binary driver, about 75 systems btw... So, what kernel am I running? Oh, the stock one that came with red hat el 4, have there been security updates? YES, have I updated NO! because that is 75 systems I have to boot into text mode, rebuild the Nvidia drivers, rebuild the sata drivers, and reboot back to X windows... and that's if everything just works... I've had it not work before. Then of course you have to wait at least 2-3 weeks after red hat releases a new kernel before nvidia publishes the new version of the driver, and all in all its just a huge headache.
Binary only drivers are here to stay folks, we aren't going to abolish them, and as long as Linus is in charge of the kernel we aren't going to get a stable ABI, so, kernel update means recompile all your drivers... Any way to ease this burden is a GOOD THING because it encourages people to update their kernels. upgrading a kernel right now on any somewhat complex system, or anything that might not be 100% supported (IE wifi, some network cards, some storage devices and video cards) means a huge headache every single time a new kernel is released (by the major vendors at least 6 times a year). I estimate that if I were to keep my system updated it would take an additional 6-700 man hours per year, that is 30,000-35,000 dollars at $50/hour (which is low), you have to figure 1+ hour per system 75 systems, 6 times a year...
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