Forgot your password?
typodupeerror
Programming Software IT Technology Linux

Linux Kernel To Have Stable Userspace Drive 309

Posted by Zonk
from the users-are-the-future dept.
liquidat writes "Linus Torvalds has included patches into the mainline tree which implement a stable userspace driver API into the Linux kernel. The stable driver API was already announced a year ago by Greg Kroah-Hartman. The last patch to Linus' tree included the new API elements. The idea is to make life easier for driver developers: 'This interface allows the ability to write the majority of a driver in userspace with only a very small shell of a driver in the kernel itself. It uses a char device and sysfs to interact with a userspace process to process interrupts and control memory accesses.'"
This discussion has been archived. No new comments can be posted.

Linux Kernel To Have Stable Userspace Drive

Comments Filter:
  • by Billly Gates (198444) on Sunday July 22, 2007 @02:29AM (#19943751) Journal
    A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations. While this is not a kernel one its a good compromise as proprietary drivers are here to stay as much as it would be great if we had free gnu ones inside the kernel.

    I wonder if it would be easy to port it to windows and macosx? IT would be cool for hardware makers to have a driver that works with all operating systems with minimal effort in porting. Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.

    • by chromatic (9471) on Sunday July 22, 2007 @03:03AM (#19943897) Homepage

      Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.

      If only there were some magical pool of experienced labor just waiting to write and maintain, in perpetuity, Linux drivers for any manufacturer of any hardware....

      • exactly. the fact that there aren't linux drivers for every piece of hardware does reflect very poorly on the hardware manufacturers. the kernel developers called their bluff on this a while back (as you allude to). it soon became clear that "we only have so many programmers working for us" and "why should we support a niche operating system?" are totally bogus reasons used to spread fud. what the real reason is, i can only speculate, but i'd tip on it having something to do with microsoft.
    • by kasperd (592156)

      I wonder if it would be easy to port it to windows and macosx? IT would be cool for hardware makers to have a driver that works with all operating systems with minimal effort in porting. Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.

      It might help a bit. But for a lot of hardware they are not going to be shipping this driver for Windows. If possible they are going to ship a user mode driver to be able to claim that their hardware

    • If this brings us closer to using (possibly unreliable) windows drivers, a major reason for using windows will be gone.
    • by Peaker (72084)
      I, for one, am glad that proprietary drivers are so poor, because it encourages free drivers to be written instead.

      These are not only free-er, but usually of better quality too.
      • I, for one, am glad that proprietary drivers are so poor, because it encourages free drivers to be written instead.

        These are not only free-er, but usually of better quality too.

        I'm still waiting for a Free 3D driver for my Radeon 9800 Pro Mac Edition. (Not for much longer, though, since I'm moving to an all-OSX setup on my next computer...)

        -:sigma.SB

        P.S. no, the R3xx DRI code in the Xorg tree did not work. Not even accelerated 2D.

    • Not high performance (Score:2, Informative)

      by eclectro (227083)
      From TFA there is no DMA access to kernelspace. So other than keyboards and mice I don't see how this can be practical for anything, other than embedded applications as the article alludes to.
      • Re: (Score:3, Interesting)

        by Tony Hoyle (11698)
        USB drivers for example. There's no reason for anything using USB to be in kernel space - it just doesn't need the performance.

        Ditto for filesystem drivers, although performance matters there - you'd have to design the driver API to minimise context switching.

        I don't think anyone's expecting userspace IDE or graphics drivers.

      • Re: (Score:3, Interesting)

        by TheRaven64 (641858)
        Safe DMA will be possible in the relatively near future. Modern systems are starting to include an IOMMU, which makes this simpler; you simply set up a mapping so the device can only write to or read from the process's address space, and then it can do any DMA it wants safely. Current AMD chips include something called the 'Device Exclusion Vector'. This isn't a full IOMMU, since it doesn't handle translation, but it does do protection. You can tell the DMA controller that the device is only allowed to
    • by suv4x4 (956391)
      A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations.

      You can't have a "stable kernel api for drivers". The kernel might be super stable but since it gives kernel mode access to the drivers, the drivers can still crash the system if poorly written.

      That's after all, the entire problem, and why we have userspace drivers. And why Vista has userspace drivers.
    • Since this is GPL then neither MS or Apple would dare touch it. If it was BSD then it might be possible that Apple might adopt it but they are not going to put something into their kernel that they don't own. The same goes for MS with the added difficulty of their operating system not being POSIX compliant.

      This is why I am prefer BSD license over GPL. Though, I am sure the majority of the readers on here would disagree with me. Anytime I look at open software I always check if there is a BSD licensed eq
      • Re: (Score:2, Informative)

        This is why I am prefer BSD license over GPL.

        This is why I am prefer people who bother to learn English grammar.

        Since this is GPL then neither MS or Apple would dare touch it.

        I'm not sure they have to. For example, FUSE, an API for developing a filesystem in userspace, is GPL'd in its entirety, except for the library, which is LGPL'd. There is a Mac port, and the Mac kernel part is BSD licensed -- but the rest of it is probably the same GPL'd code. There's also talk of a Windows port, though I don't see

        • Re: (Score:3, Insightful)

          by drinkypoo (153816)

          Can you give me one good reason why I should give you code for free, that you can then turn around and sell, without paying me a dime?

          That's an easy one - when it's more important to you that the world use your implementation than that you get credit and/or other rewards for it.

          Examples include the BSD TCP/IP stack, which was rumored to have been incorporated into Windows in, I believe, Windows 2000. It's quite believable because at this time Windows' stack became much faster and more mature, basically overnight. Vista, as you may know, has an all-new stack in which Microsoft reproduced several bugs from antiquity (Vista RC was suscept

      • Since this is GPL then neither MS or Apple would dare touch it. If it was BSD then it might be possible that Apple might adopt it but they are not going to put something into their kernel that they don't own.

        You can't copyright an interface (although you can copyright the documentation of the interface. See POSIX). To make this work on a different kernel, you probably couldn't re-use much of the code anyway, so it's not much of a problem. You'd just re-write the kernel component, and share the userspace part. Since the userspace part only depends on stuff shipped with the OS, it is subject to one of the GPL exemptions. Take a look at how DRI works. You have the DRM (Direct Rendering Module) part, which i

    • Re: (Score:3, Informative)

      While this is not a kernel one its a good compromise as proprietary drivers are here to stay as much as it would be great if we had free gnu ones inside the kernel.

      No, they are not.

      It's happened before -- Broadcom for example. For the longest time, you could only run broadcom wireless with ndiswrapper. Now there's an open driver. You need only copy the firmware out of the Windows/OSX driver, and I imagine there might even be some free firmware developed eventually. This doesn't mean ndiswrapper is dead --

      • by baadger (764884)
        I tried for days to get WPA and WEP working with the native bcm43xx driver and failed. The thing would receive wireless traffic (I could stick the card into monitor mode and capture packets from the air) but refused to connect to anything but unencrypted networks.

        This may have been because the native Broadcom driver doesn't support the latest firmware (v4). I gingerly installed ndiswrapper and it just started working, and as an added bonus I can use the whizz cool Network Manager.

        So the native Broadcom driv
    • by DrSkwid (118965)
      > A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations.

      Now they can write poor quality and buggy implementations against another API.

      • If the API is stable, then they can spend time fixing bugs that they used to spend updating their code to today's API.
  • Full circle? (Score:5, Insightful)

    by MichaelSmith (789609) on Sunday July 22, 2007 @02:30AM (#19943769) Homepage Journal
    Perhaps in ten years time Linux will be a microkernel
    • by Goalie_Ca (584234)
      And the debate [google.com] continues!
    • by Tumbleweed (3706) * on Sunday July 22, 2007 @03:18AM (#19943973)
      Microkernels are the wave of the future.

      And always will be. :)
      • They probably will be now. Monolithic kernels give better performance on single-CPU machines, where you use shared memory for communication and don't want any context switches slowing you down. Microkernels with an asynchronous message passing mechanism, however, are better suited to large-scale multiprocessor boxes. With current hardware being 2-4 core, and this only looking to increase in the future.

        Of course, now, a lot of the people who were saying microkernels were the future are saying that type-t

    • by giminy (94188)
      I've been thinking the same thing...first FUSE, now this. More and more of the kernel is going into userspace services, and these are the 'biggies.' It's really a welcome change. Albeit a strange one, given the great Torvald/Tanenbaum debate.
      • by baadger (764884)
        Torvald's is a pragmatist, if this is the same user space I/O framework I read about a while ago then there was a good case made for it when some guy ported a driver to it and significantly reduced the complexity and lines of code (and as I recall the number of ioctl's)

        Window's has a userspace driver framework as well as a FUSE equivalent (I think) so really Linux isn't going any more toward being a micro kernel than Window's is.
        • Re: (Score:3, Informative)

          by init100 (915886)

          Window's has a userspace driver framework as well as a FUSE equivalent (I think)

          There are two ways to make new filesystems for Windows. You can make an Installable FileSystem (IFS) driver that runs in kernelspace, and you can make a Shell Namespace Extension to the Explorer shell. There is no shell-independent way of making userspace filesystems in Windows that I know of.

          Note that I'm not a Windows programmer, but a Unix one. I did look into this however, when I was thinking of making an SSHFS equivalent for Windows, so that my friends and family could access my SSH server. I never

    • by Pecisk (688001)
      Linux kernel are usually referenced as _hybrid_ type kernel. For example, Ubuntu and Debian built EVERYTHING they can in modules, so their kernels are more microkernels than monoliths.
      But I really doubt that Linux will be pure microkernel sometimes, because...there is no need for it, _IMHO_.
      • by bcmm (768152)
        Modularisation doesn't make it a microkernel. A loaded kernel module runs in kernel space just like any other kernel code, and will bring down the rest of the kernel if it crashes. A userspace driver (or one of the many daemon's doing all the interesting work for a true microkernel) should be able to segfault without bringing the kernel down.

        Of course, if it's doing something really vital like managing the root FS (possible in a proper microkernel but not in Linux), you could be screwed anyway.

        In any case
        • by bcmm (768152)
          I should point out that IIRC the Linux kernel has been made to run on top of the L4 microkernel. This is not the same as Linux itself being a microkernel.
      • by baadger (764884)
        > Ubuntu and Debian built EVERYTHING they can in modules

        andrew@ziggy ~ $ lsmod
        Module Size Used by
        nvidia 8105272 24
        andrew@ziggy ~ $
        Gentoo user ;)
    • by Weezul (52464)
      I'm pretty sure I've HURD of this userland driver idea before.
    • A microkernel. What, like this [mklinux.org]? :-)

  • by TheRistoman (1062158) on Sunday July 22, 2007 @02:33AM (#19943781)
    So I immediately thought of a spaceship running Linux... I mean, could it really be otherwise?
    • by Romwell (873455)
      I was just about to ask if I'm the only one who read Uberspace Drive (which is sorta like Warp Drive, only cooler), but in spite of Slashdot instinct, I searched the thread first =) Pleeeeeeeeeasse mod parent up =)
  • Finally... (Score:4, Insightful)

    by Statecraftsman (718862) * on Sunday July 22, 2007 @02:54AM (#19943851) Homepage
    The lack of a stable userspace driver api was that last thing stopping soccer moms and grandmothers from running Linux on the desktop.

    My sarcasm is so extreme, I think what I said above may have actually been true.
    • Re: (Score:2, Insightful)

      by zullnero (833754)
      Considering that the major blocker for the average person in regards to making the switch to Linux happens to be driver support, then yes, it could make it easier for "soccer moms and grandmothers". Of course, that should be pretty obvious from even the article summary.
      • no, the major blocker is "it's not windows"
  • by Zork the Almighty (599344) on Sunday July 22, 2007 @03:06AM (#19943905) Journal
    Maybe this path will ultimately bring proprietary drivers to Linux in force, but I think Linus has made the right decision. We should start looking for other ways to convince companies to write open, GPL drivers.
    • by Alioth (221270)
      It's not just proprietary drivers, it's open source ones too, especially for niche hardware. You're never going to get your kernel driver accepted by the high priests of the Linux kernel team for a piece of hardware with half a dozen users, so you are doomed to rebuilding the module every time you do a yum update, and your distro has a new point version of a kernel. It really kills the usability of Linux when this happens.

      Fortunately, for USB devices, this has existed for a while. (Indeed, there's little re
  • by Animats (122034) on Sunday July 22, 2007 @03:08AM (#19943915) Homepage

    QNX has had user space drivers along somewhat similar lines for many years. In QNX, all the drivers are in user space, which makes for a much smaller kernel. Here's a simplified article on QNX driver writing. [embedded-c...europe.com]

    The Linux approach has the problem that Linux doesn't have the message passing primitives that QNX does. So there's a special purpose mechanism to hook up these new user-space drivers to the I/O system calls. In QNX, "open", "close", "read", and "write" are actually C library functions that call MsgSend to do the work. (System V IPC isn't really suitable; it's asynchronous, which means a few extra scheduler events for every message pass when you try to use it for something that works like a subroutine call. Long story.)

    Unfortunately, on x86 hardware, you can't protect the system from a user level driver and still give the driver direct hardware access. IBM VM mainframes get this right, but x86 does not. On the other hand, you can have channel drivers for the various types of x86 channels (SCSI, FireWire, USB, etc.) and make other drivers work through them.

    User-level drivers cost you at least one extra memory copy of the data. That's not too bad in practice. I did a FireWire video camera driver for QNX, and when transmitting 640x480 24 bit images at 15fps, it took about 3% of a Pentium 4 CPU.

    • Re: (Score:3, Informative)

      by wellingj (1030460)
      http://www.osadl.org/UIO.uio.0.html [osadl.org]

      They impression that I get is that this is in order to use SOC's more effectively. Things like using PWM and GPIO on SOC's aren't that portable across different brands of micros. This would be an easy way for all the SOC chip makers (Freescale, Atmel, Renesas, Marvell, ect...) to create the bottom level of the driver and use the same userspace driver for embedded developers. this will still give the developers enough leway to mess with things if they need to.
      I could be
  • High time! (Score:3, Interesting)

    by iamacat (583406) on Sunday July 22, 2007 @03:28AM (#19944007)
    Just because some code controls a piece of hardware doesn't mean that a runaway pointer in it should cause a panic or even corrupt files by messing up filesystem buffers. This will also enable device drivers to make use of all available userspace libraries, with sophisticated algorithms that would never be used if all code had to be written from scratch and non-pagable.
  • by AlphaWolf_HK (692722) on Sunday July 22, 2007 @03:34AM (#19944037)
    FWIW, not trying to troll, but thought I would point out that this feature is one of Vista's improvements over XP, and simultaneously the primary reason why Vista's compatibility isn't that great right now, and thus the primary reason why many people don't switch to Vista yet. Most of the hardware vendors have to make big changes to their drivers in order to accommodate this, especially nvidia who has to make about 4 different user space drivers (one for d3d, one for opengl, and an SLI version of both of those.) This is a good thing to have for both security and stability reasons, and I was waiting for when somebody would add this to the Linux kernel.

    Linux has the advantage in that with Linux you can use both the old "kernel only" drivers, and the user space drivers at the same time. Vista could have done this as well, however Microsoft felt that if they allowed this to happen, then most hardware vendors would be lazy and continue to use their old kernel mode drivers, thus defeating the purpose. And to be honest, I agree with them. Linux doesn't need this on the other hand, as eventually somebody who is interested will make these kinds of changes to all of the open source drivers anyways as needed, which can't really happen because most windows drivers are binary only, so Linux can more or less take the "phased change" approach.

    Disclaimer: I use both Vista and Linux (gentoo is my preferred distribution,) and am not afraid to say that I don't hate either of them, and rather like both of them.
    • Re: (Score:3, Informative)

      by Anonymous Coward
      You're half right.

      Vista has partially user-space drivers for graphics, where the majority of the driver is in user space, and the kernel-mode component just allows communication between the driver and the hardware. Linux already has a similar architecture, as does MacOS X.

      Second, it has user-space USB drivers. Which Linux and MacOS X have both had for ages.

      It also has user-space printer drivers, which is no big deal - printer drivers hae been user-space only for years on most operating systems.

      No other driv
    • by wwahammy (765566) on Sunday July 22, 2007 @04:16AM (#19944211)
      Actually it was there before Vista. Windows Media Player 11 came with the first version of the userspace driver framework. I think its used for media players that sync with WMP.

      My understanding was that Microsoft recommended companies move to userspace not that it was required. To be fair though, I know very little about WDDM so they might have different requirements.

      When I read the headline, the first thing I couldn't help but think was if the roles were reversed there would be hundreds of people saying "Good to hear you got something Linux had for a year already." Good ideas are good ideas. Why can't people just be happy when their ideas are recognized as good by others?
  • microkernel (Score:2, Funny)

    by jb.cancer (905806)
    well i remember Linus comparing microkernels to 'masturbating' sometime back. It seems as h/w continues to grow in power and several other factors contributing, pushing more stuff to userspace will now look a better idea after all.
  • by kscguru (551278) on Sunday July 22, 2007 @04:06AM (#19944171)
    Maybe I'm unique in that I not only RTFA, but browsed the patches themselves.

    Which led me to the conclusion that this patch set is worthless. It allows remapping of memory-mapped I/Os to a userspace app, and allows a thread to "wait" on an interrupt. Both are nice ideas, and it would be very easy to implement a nice serial port driver with the new APIs. (As any kernel hacker knows, serial port is one of the simplest device drivers; it's easy.)

    The new API is completely useless for binary-only drivers. I/Os / IRQs are enough for extremely simple devices - these are, after all, the primitives for talking to hardware. But if this were all a driver needed, don't you think Nvidia / ATI would have used this model for shim drivers a long time ago? Simple things like DMA and PCI configuration access are not present - but to be fair, those are implementable with these primitives. Reality check: real world drivers are a lot more complicated. What is impossible is fast thread switching, kernel synchronization primitives, access to the network stack (wireless!), ring-0 CPU instructions, real-time timing access, and the huge reduction in context switches / cache flushes that comes from running within the kernel (moving code to user-mode increases latency by a factor of 3, roughly). Kiss the lag-free desktop goodbye as hard drive latency skyrockets, watch your 3D framerate drop by 70%, see your webcam stutter into unusability.

    The kinds of drivers this API can support are the simplistic ones, the kind that are already GPLed and are already in the kernel, the 80% of devices in this world Linux has always had good support for. The kinds of drivers this API cannot support are 3D graphics, high-performance disk or networking, wireless networking, latency-sensitive USB or Firewire, the virtual devices (VMware, KVM, Xen, even /dev/tty) - notice that most of the devices Linux supports poorly (and all the common binary-only drivers) fall into this list.

    To be fair, the official (e.g. from Linus) announcements I've seen only claim this interface is useful for embedded devices (which tend to code for a specific kernel, and not get updated). No official announcement claims the new API will help binary-only drivers. It's just the OSS-zealot crowd making unwarranted assumptions. Yes, this is the bad news: the stable userspace driver API will do nothing to solve binary-only driver dilemmas. Sorry.

    • by suv4x4 (956391) on Sunday July 22, 2007 @05:58AM (#19944545)
      What is impossible is fast thread switching, kernel synchronization primitives, access to the network stack (wireless!), ring-0 CPU instructions, real-time timing access, and the huge reduction in context switches / cache flushes that comes from running within the kernel (moving code to user-mode increases latency by a factor of 3, roughly). Kiss the lag-free desktop goodbye as hard drive latency skyrockets, watch your 3D framerate drop by 70%, see your webcam stutter into unusability.

      Nice rant there. Let me summarize it:

      "What is impossible in user space driver is kernel space features".

      No shit. That's the point of a user-space driver. If you give a user-space app access to ring-0, it's no longer user-space. Or did you imagine there's some sort of unwet water that the stupid developers of the kernel keep missing.

      The user-space driver is not set to replace all kernel mode drivers. Just like Vista, it's set to replace *some* of them, for example USB devices with low traffic. It's not a solution from heaven, it's just a reduction of fail-prone pieces that lurk in your system.

      If you RTFA you probably had to read the summary as well where it's said user-space drivers aren't suitable for high-performance gear such as graphics cards.
    • Re: (Score:3, Interesting)

      by wellingj (1030460)
      But it does help embedded developers who need access to an SOC's hardware like PWM and GPIO and A2D.
      A lot of people really are missing the point here that this patch really doesn't do much for x86, but
      does great things for SuperH PPC and ARM.
  • This seems to be an on-going trend in the kernel: FUSE, libusb, libraw1394 and ALSA all (to a certain extent) export what were traditionally kernel-bound services/drivers to user-space, while leaving the minimum necessary kernel-side mechanism, such as VFS redirection, and low-level I/O and interrupt handling. However they all do this in different ways according to the needs of the hardware. So while a generic API may be a good for unusual pieces of hardware, might it not be a good idea to develop applicati
  • Linux needs a stable ABI for drivers. Insisting that vendors release drivers for every dist, or that they open source their code is unrealistic. Open source is obviously desirable but it's still not much to end users who wouldn't have a clue how to build it.

    It would be great if dists would support an ABI and produce some dist neutral packaging system that allowed drivers to be installed / uninstalled easily by mere mortals no matter what dist they had.

Saliva causes cancer, but only if swallowed in small amounts over a long period of time. -- George Carlin

Working...