Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Novell Delivers Device Driver Breakthrough 241

Posted by ScuttleMonkey from the hopefully-the-companies-will-actually-start-writing-them dept.
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."
This discussion has been archived. No new comments can be posted.

Novell Delivers Device Driver Breakthrough More

Novell Delivers Device Driver Breakthrough

Comments Filter:

  • Marketing blurb (Score:2, Insightful)

    by McGiraf ( 196030 )
    The Article is a merketing blurb, anybody knows how it's actualy implemented?

  • No need for Suse Linux (Score:5, Funny)

    by bizzynut ( 887594 ) on Wednesday May 17, 2006 @03:25PM (#15353726)
    Plan 9 offers everything you would expect from a modern desktop OS. So there is no need for Suse Linux.

  • When my copy of Windows fails... (Score:5, Insightful)

    by Osrin ( 599427 ) * on Wednesday May 17, 2006 @03:26PM (#15353732) Homepage
    ... 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.

  • Something is breaking, that's for sure (Score:5, Informative)

    by Wesley Felter ( 138342 ) <wesley@felter.org> on Wednesday May 17, 2006 @03:28PM (#15353748) Homepage
    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.
    • If the hardware manufacturers publish thier source code it wouldn't be a problem. The only device I have that needs updated drivers from the manufactuerer is my Nvidia graphics card. Everything else is supported in the kernel.
      • If the hardware manufacturers publish thier source code it wouldn't be a problem.

        Not necessarily. For example, if a vendor publishes source code for a driver, it takes months for that driver to appear in the next stable kernel, and likewise months until the next SLES or RHEL quarterly update. Novell's process allows the vendors to ship drivers whenever they are ready, without waiting for anyone else. But as I said, the cost is that the vendors have to do a lot of work.
      • Hardware manufacturers often don't release the source code because it costs money to do that. You can't just do tar cj ~/MyDriver | post it on the Web site. There must be an approved process because everything that for-profit companies do affects their paying customers. For example, a customer decides to recompile the driver and something is wrong; he will call the company, and that's loss of $100/hr right there. Who is paying for that? Not the customer, since it takes a lot of arrogance (MS) to charge
    • They took a problem, wrapped a marketing program around it, and now it's an enterprise feature!
    • Yeah - that sounds exactly like the Windows model... You get working drivers with the OS, and manufacturers update them when the OS requires it. For the vast majority of people who want to RUN linux rather than hack it this sounds like a GOOD thing.

      If you do want to hack your driver source and compile it yourself, then nothing is stopping you from doing it for open source drivers.

  • Shim driver? (Score:3, Informative)

    by tepples ( 727027 ) <tepples.gmail@com> on Wednesday May 17, 2006 @03:30PM (#15353759) Homepage Journal

    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)

    by pe1chl ( 90186 ) on Wednesday May 17, 2006 @03:30PM (#15353767)
    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)

    • Re:Version numbering (Score:3, Informative)

      by Shisha ( 145964 )
      This makes binary and externally compiled drivers (including nvidia and vmware drivers that I use) break on every kernel update, and probably unnecessarily

      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.
    • You could script the nvidia/vmware driver build, as part of the boot process (in pseudocode):

      if (!`modprobe nvidia`) { /sbin/build_nvidia
      }

      if (! `modprobe vmware`) { /sbin/build_vmware
      }

      If you did that, you would never have to recreate the drivers again, infact, i think i might see if i can manage that, and submit it to the gentoo devs.

    • Re:Version numbering (Score:3, Informative)

      by lmfr ( 567586 )
      You don't need to reboot.

      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 /etc/rc.local (or /etc/rc.d/rc.local):
      modprobe -q module || script_to_install_driver

  • ok... (Score:5, Interesting)

    by reynaert ( 264437 ) on Wednesday May 17, 2006 @03:35PM (#15353803)
    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.
    • It only gives vendors an excuse to call their shitty binary-only drivers "Linux support".
      They do that now already (NVidia and ATI being two most prominent examples), so what's your point? Besides, it's not like they are lying: the drivers allow you to use their hardware with Linux, what should it be called if not "Linux support"?
      • SUSE support maybe? If a company "supports Linux" then I am definately going to be bugging the hell out of them and giving them poor reviews if I can't make a supported product work on my Gentoo box.

      • Re:ok... (Score:3, Insightful)

        by jejones ( 115979 )
        Besides, it's not like they are lying: the drivers allow you to use their hardware with Linux, what should it be called if not "Linux support"?

        Can I use the hardware with Linux on ARM? MIPS? PowerPC? Do they guarantee feature and speed parity with Windows drivers? Will they continue to support the hardware, or, like ATI, will they only bother to support their most recent hardware?

        At best it's monogluteal Linux support.
    • This is only going to work if you're using SuSE.
      <sarcasm>But of course! Since Linux is the Open Source poster child, pretty soon all vendors and "distros" will create something like that! Of course, all of them will be 100% mutually compatible...</sarcasm>

  • a new Linux device driver process (Score:5, Funny)

    by special_agent ( 88338 ) on Wednesday May 17, 2006 @03:49PM (#15353929) Homepage
    a new Linux device driver process

    Sounds more like a new marketing process.

  • 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.

      Then we would not have put up with pitiful crap like this quite so often.

        PenGun
      Do What Now ??? ... Standards and Practices !
     

  • So enabling YasT to handle kernel modules... (Score:3, Interesting)

    by mr_mischief ( 456295 ) on Wednesday May 17, 2006 @04:29PM (#15354217) Journal
    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?

    • 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?

      Any code that is compiled locally is by definition untested, and many people don't want to run untested drivers.

      But if you want Gentoo, you know where to find it.
    • I don't know why Dell is partnering on this. They've had dkms [dell.com] for a while now, and it sounds like it does pretty much the same thing. I've used it in PCLinuxOS [pclinuxos.com] for about a year now for loading NVidia drivers without needing to compile anything, and it works fine.
    • 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?

      What planet do you live on?
      Not only do most (and here I would wager "most" is 99%) desktop users NOT WANT to "inspect, customize or debug" a freaking KERNEL MODULE, why can't you just do that yourself? Why would you need a freaking package manager if you're going to be compiling the damn thing yourself, let alone tinkering with it?

      While
      • If I'm 99% of desktop users, why am I updating hardware drivers in the first place?

        For that matter, why am I using Linux? Especially SUSE, which is in my experience much more server-centric than desktop-centric. Knoppix, Ubuntu, or hell even Linspire should be the ones worried about updating things for desktop users.

        The main reason someone who understands code would want to sue a package manager is the same reason anyone else would -- it gets the right version of something from the right place. I could very

  • Where's the "Linux" in this? (Score:3, Insightful)

    by tmandry ( 710511 ) <{tmandry} {at} {gmail.com}> on Wednesday May 17, 2006 @04:43PM (#15354309)
    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.

    • Re:Where's the "Linux" in this? (Score:5, Insightful)

      by a_karbon_devel_005 ( 733886 ) on Wednesday May 17, 2006 @05:19PM (#15354587)
      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.

    • A bit unfair... (Score:3, Informative)

      by IANAAC ( 692242 )

      All this does is benefit Novell, and once companies write up their drivers, where are the rest of us that use real Linux left?

      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.

  • Ok, I'd say relax people (Score:5, Insightful)

    by pavera ( 320634 ) on Wednesday May 17, 2006 @05:37PM (#15354689) Homepage Journal
    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...
  • Soaring high in the sky
    He may be small, but only in size.
    As-tro-turf, As-tro-turf!
    ...

  • Linux "Device Driver" pains (Score:3, Interesting)

    by BeforeCoffee ( 519489 ) on Wednesday May 17, 2006 @07:20PM (#15355180)
    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.

    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 ... 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.

    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

  • How is it good? (Score:3, Interesting)

    by shutdown -p now ( 807394 ) on Wednesday May 17, 2006 @09:27PM (#15355719) Journal
    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.

  • DKMS From Dell (Score:3, Informative)

    by PhYrE2k2 ( 806396 ) on Thursday May 18, 2006 @11:41AM (#15358380)
    http://linux.dell.com/projects.shtml#dkms [dell.com]

    Sounds like dkms from Dell:


    DKMS stands for Dynamic Kernel Module Support. It is designed to create a framework where kernel dependent module source can reside so that it is very easy to rebuild modules as you upgrade kernels. This will allow Linux vendors to provide driver drops without having to wait for new kernel releases while also taking out the guesswork for customers attempting to recompile modules for new kernels.

    For veteran Linux users it also provides some advantages since a separate framework for driver drops will remove kernel releases as a blocking mechanism for distributing code. Instead, driver development should speed up as this separate module source tree will allow quicker testing cycles meaning better tested code can later be pushed back into the kernel at a more rapid pace. Its also nice for developers and maintainers as DKMS only requires a source tarball in conjunction with a small configuration file in order to function correctly.

    The latest DKMS version is available here. Also, you can read this Linux Journal article or this more recent Power Solutions paper or this even more recent Ottawa Linux Symposium paper about DKMS for more information. You may also participate in the dkms-devel mailing list. This project is maintained by Matt Domsch, and was formerly maintained by Gary Lerhaupt.

Slashdot Top Deals

God made the integers; all else is the work of Man. -- Kronecker

Close