November 23, 2014
 
 
RSSRSS feed

Infernal Devices

An Interview with Andrew Morton

  • August 4, 2005
  • By James Turner

One of the most frequently cited difficulties transitioning to Linux (especially on the desktop) is that it can be difficult to find and integrate device drivers for new or obscure hardware. In addition, even when drivers are available, they may involve procedures that still strike terror into the hearts of newbies, such as recompiling the kernel. But is this really necessary? I rang up Linux Kernel guru Andrew Morton to discuss the state of Linux devices drivers in 2005.

LinuxPlanet: What are the limitations on binary drivers as you move from major release to major release and then inside of the point releases?

Andrew Morton: Well we can change kernel internal interfaces at any time. And obviously there are also issues with making sure that the kernel itself and the driver were compiled with the same version of GCC and the same kernel configuration options.

LP: How much of the way device drivers are engineered is truly necessary, and how much would you think could be standardized more?

AM: We don't attempt to standardize it all really in the public kernel. We feel it impedes our progress, our ability to improve the kernel. You will probably find that downstream vendors would be more constrained than we are, so you'd probably find that particular versions of Red Hat do use a more tightly defined compiler version and the kernel configuration options.

LP: The question I'm getting at is one of the complaints you hear about the Linux kernel, and you can kind of understand it from a manufacturer's point of view, is that assuming they don't want to move their device driver directly into the kernel, you know there's no way that they want to keep 97 different binary drivers out there and have to keep tracking them.

AM: It's a problem for them, yeah; and basically we really don't do anything to accommodate them because that would tie our hands and frankly we're philosophically not particularly sympathetic to the problem.

LP: Doesn't this create a chicken and egg problem where hardware manufacturers don't release device drivers for Linux because there isn't enough of a user base to justify maintaining all the different binary drivers, and users don't adopt because of poor device driver support?

AM: Yeah; but that doesn't mean that the manufacturers have to bend over backwards to target the current public development kernels. I mean if they target Fedora Core 4, that's a big slice of the market and that's not going to be as quickly a changing thing as the public kernel.

LP: But even then, I guess you could say "I'll take the top five", but there's so many publicly available distros out there that how do you pick which ones?

AM: Well, the moral here is don't try and ship a proprietary driver...

LP: But even for ones who said okay fine; we're going to go and make our driver open source, do you think that maybe there could be a little bit more stability in APIs, at least inside of major releases. So you can say to manufacturer that you might need to revamp your driver between 2.4 and 2.6, but not three times inside of a point release?

AM: Well we don't change it all that often. I mean yes we do change the API into drivers sometimes. But in a particular sub-system whether it for serial or network or whatever, we'd probably only change each sub-system once--it wouldn't surprise me if it was once a year or once every two years. It's not a thing we do particularly rapidly because the API of course is stable and any time we change it we've got to change every device driver. So it's not as if we change it particularly frequently.

LP: Right; but there is always that threat that tomorrow might come and you've got this work you weren't expecting.

AM: Yeah; that's true. Although, it's not as if you have to respond to that change tomorrow because it takes a month for that change to actually propagate into kernels which an appreciable number of people are using.

LP: Do you get the sense that we're going to start to see more vendors coming on board? It seems like the--the ones who are the real tough nuts are the ATIs and the nVidias and to some extent, some of the wireless Ethernet devices seem to be tough nuts to crack?

AM: Slowly; yeah, certain manufacturers are coming across and working with other developers and some of the Taiwanese manufacturers are doing the right thing and we're seeing more vendor supportive drivers coming into the tree than we used to. I wouldn't say it's accelerating but it's happening at a steady pace, not a particularly fast pace,

LP: Do you think you could see model where if nVidia said "You know there's just some part of this that isn't going to change much and we need to keep to ourselves" for whatever reason they believe that they need to do that. Is there some model you could get where they could shim in something that could be easily maintained to whatever the current API is for today but they can still have their proprietary backend that shims into that?

AM: Yeah; I think that is technically possible in that they already have a shim which interfaces their driver with the rest of the Linux world and probably it would ease their life if that shim was shipped and maintained in the public kernel. But that's not a thing which anybody would want to do, I'm afraid.

LP: So basically, if they're not willing to go all the way they're not going to be allowed to go halfway?

AM: Yeah; it's tough, but there is logic behind it.

Sitemap | Contact Us