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."
The Article is a merketing blurb, anybody knows how it's actualy implemented?
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.
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)
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.
they are designed to hide bugs in the hardware/firmware,
I was always under the impression that the specs were closed to ward off copycatting from competitors.
Where does the school board find them and why do they keep sending them to ME?
It is a breakthrough, because having a shitty, flaky, unfixable and unsupportable binary-only driver is better than having no driver at all. Don't use it if you don't like it. As someone who writes closed source device drivers, I sincerely welcome this. Now, if someone just convinced Linus to add this (or similar functionality) to the "vanilla" kernel...
"It is a breakthrough, because having a shitty, flaky, unfixable and unsupportable binary-only driver is better than having no driver at all."
No, its not. See how when you want to use an ethernet adapter, you just put it in the machine and it works? See how when you want to use a wireless adapter, its a huge hassle, barely works, and will likely cause you machine to randomly hang?
If people keep accepting binary only shit like this, then the situation will just keep getting worse. Soon, you won't be able to buy any hardware that works, you will only be able to buy hardware + crappy driver for some OS you may or may not use. Demand documentation so the people writing the kernel can write the drivers, and everything will work smoothly and without any hassles, in any OS.
From what I can see (too much marketing crap), it looks like they have an option in YaST to add an ISV's repository.
So, the ISV builds a package for their module and sets the dependencies and YaST allows you to update the module/kernel without breaking the dependencies.
Not much of an accomplishment at all (if that is all there is to it). Which would explain why they resorted to so much marketing crap in their announcement.
Copycatting what? What memory address to write what bytes to? What is copying that going to accomplish? All it would do is let your competitors write drivers for your hardware, it wouldn't help them copy your hardware in any way.
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."
So, YaST now has the ability to include ISV repositories ... and Novell will tell people who sign up with them when the interface changes?
Sorry, but I'm not seeing the "breakthrough" here.
Is not as hard as some make out. It's worth spending a few hours learning how to build your own kernel, it will reward you.
... Standards and Practices !
Then we would not have put up with pitiful crap like this quite so often.
PenGun
Do What Now ???
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.
Buy hardware that is supported. Yes it's a pain to do the research, but it's worth it. I have a Shuttle XPC and wanted to install their wireless add-on that doesn't require a PCI slot. I worried about drivers until I found that it uses the ZD1211 chip for which ZyDas provides an open source Linux driver. Then I learned that there is a sourceforge project to rewrite the driver so it's suitable for integration into the mainline kernels - 64bit included. They plan to get into 2.6.17 or 18 kernels, so wireless may well work out of the box when I upgrade to Fedora 6 in the fall. For now it's possible to make it work the hard way (download/compile) without ndiswrapper.
There are other cards with this chip and there are other chips with native Linux drivers in various states. The future looks good.
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
So enabling YasT to handle kernel modules... is now a breakthrough.
I mean, all this appears to be is distribution of precompiled kernel modules being handled by the package manager. This is not a good thing, let alone a huge advance.
How about a package manager that downloads the code, lets you inspect, customize, or debug it, then compiles it and adds it to your modules list once you approve it?
Linux got to where is is precisely because of the kernel devs not producing a stable API. Think about it, what would the kernel be if it was stripped of all the drivers? Not much use at all.
Now that Linux has a large userbase, you're arguing that is ok to relax that since some user wants binary drivers that just work. However, when you go that route, it's hard to go back because everybody *expects* the ABI to remain stable. Instead of improving the kernel, the devs will waste time sorting out ABI issues; not the best use of time.
:. Ultimate Control Dedicated/VM Servers
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.
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
You know, the argument about closed-source drivers and "the idea of open source" is getting old. If I'd want a religiously open system, I'd be running debian. Oh well, I couldn't play the games I paid for, but I'd be running a 100% GPL'ed box, so I should be happy with it, right? Since those games are closed source as well, that would be fine, ok, right? What I want is a system that does what I want, the way I want it to (which in my case happens to mean linux, YMMV), and which lets me do the things I want to do (which in my case means installing the closed-source nvidia drivers).
Sure. Then explain why there are so many OSS projects where you can find bugs in the respective bugtrackers that haven't even been acknowledged after several years, and three-figure number of comments from people who stumbled over the same thing? Hunt the mozilla and kde bugtrackers for any number of examples.
To sum it up, I'm happy with linux as it is, and I'm perfectly fine with the one or other closed-source thing on my box, be it a driver, or any commercial app like moneyplex or the dozen or so games where I've happily bought the linux version.
oh, and a word to the plan9 advocates... I can't see any reason to install that. any at all. Sounds like BeOS to me... good idea, dies (or shrinks to insificance) due to lack of apps and users. Happened to OS/2 as well, which was a shame.
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...
--
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.
It's not a question of "refusing." The issue is that they know they're not done yet.
The kernel API is a moving target because the technology -- and knowledge behind it -- is growing and evolving. One of the more perfect examples of this evolution is Linux power management. The first released API consisted essentially of suspend() and resume(). Even back in the days of APM, this may have seemed adequate, but it really wasn't. This inadequacy was driven home when ACPI happened (ugh!), and the shortcomings of suspend() and resume() became obvious. So the kernel API was changed to try and encompass it.
Whoops! It turns out that, aside from being incomprehensibly baroque, ACPI is absolutely useless when trying to address power management issues on, say, embedded systems where power and clock throttling controls are far richer and more complex. So the API is being spun again, and this time they're trying to get something more future-proof.
Besides, your complaint is specious to begin with. Microsoft has changed its device driver API at least three times in the Windows era (and probably far more in the DOS era). This didn't stop HW manufacturers from supporting it. What it did stop was old peripherals moving forward on to shiny new HW platforms. That old joystick you loved from the company that died just before Windows 98 came out? Too bad, you have to throw it away now; there's no WDM driver for it, and there certainly won't be a Vista driver for it. Oh, hmm. Looks like someone made the necessary changes to the Linux driver source so that it'll compile under 2.6.16.
It sounds like what you're really saying is that Linux is too small a market to bother with, rather than there being any intrinsic issue with publishing driver source. If the market shares of Windows and Linux were swapped, the source code issue wouldn't be; it would just be treated as part of the landscape.
Schwab
Editor, A1-AAA AmeriCaptions
Ok, I like Linux. In fact, I'd love to write software for it since, as a developer who leverages open source libraries, I feel like Microsoft has told me I'm no longer welcome.
... what there is is not abstract enough to be graced with that name. Module maybe fits. C'mon you geeks, seriously, what's the holdup here? What is the big problem with having a driver binary that just works across all minor revisions of a major version of a Linux kernel? That would be a HUGE plus for me.
So when I saw CentOS, I figured it was time to make the switch. It offered everything I needed. I went to fry's and bought the hardware for my new app server which included a cheapy HighPoint 1640 RAID card so I could setup a RAID 1 system. It said it supported Linux, so I figured I was good.
Well I wasn't good. There was source code for an open source driver from HighPoint. But trying to figure out how to package and build the thing was amazingly arcane and retarded! I HAD to install a floppy disk for godssakes. The experience of trying to bootstrap and get the damned open source drivers built for the thing was a long trip through the fiery pits. Equally evil was trying to figure out how to patch a new kernel with recompiled drivers whenever yum got me a new one. What a pain!
I'm a developer not a sysadmin. The fact that I figured out how to make my RAID card work with Linux was not a satisfying experience to me, it was frustrating and it was a waste of tens of hours over many months. You geeks who like to build kernels and fiddle with make files have at it. It's just not my thing.
In fact, I think there is no such thing as Linux device drivers
Whatever the case, the other poster who said it's not 1992 anymore had it right - we need some more slickness around drivers if we are going to win. And since I'm planning on not upgrading to the next version of windows, I would prefer we start winning on the desktop real quick.
Dave
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
Simple: when your parents/friend/gf asks you about "that Linux thingy" that you use on your desktop, you can burn a SuSE DVD for them and know that their hardware will work with minimal effort on their part. Myself, I'll keep my Debian where I can tweak things to my heart's content. Everyone wins.
I am not trolling. I am one of the many, many PC users that are not code monkeys. I use Windows because (for me) it 'works'. By 'works' I mean that my PC does what I want it to do 99.99% of the time. I have however an older laptop (It's a Haus laptop: Pentium 2, 1.4Ghz, 256MB RAM, 20GB Hard disk - Haus were an own-brand badging for the former jungle.com now owned by Argos) on to which I have installed Mandriva. The experience has been interesting. I can do all sorts of OSS stuff like play OSS games and type up OSS documents and so on. The fun stops, however, when I want to anything that an ordinary PC user might want to do. I cannot surf the web because there are no Linux drivers for my Netgear or Belkin wireless cards. I cannot send or receive email because of the same reason. I cannot download new software because of the same reason. I cannot print anything because I do not have a linux driver for my printer (Lexmark X1170 - if you know of one let me know).All this means is that my Linux laptop is a mere curiosity and not a powerhouse driven by cutting edge OSS technology
Could the people who know all about APIs, ABIs and Microkernels and so on PLEASE stop bickering and just write some drivers.
Open Source of course.
Travelling forward in time at a rate of 1 second per second.
Sounds like dkms from Dell:
when you see the word 'Linux', drink!