Linux too please

Posted Aug 29, 2005 20:31 UTC (Mon) by mgb (guest, #3226)
Parent article: Fedora: RFC: X.Org X11 modularization project - rpm package driver naming

"The ability for us to update a single driver, and release that
single driver to users is an important thing for a modern OS, in
particular for desktop systems."

If only the kernel hackers could keep the driver API stable for
more than five minutes, Linux-based systems could work with a
lot more widgets and Linux would be a lot easier concept to sell.

Linux too please

Posted Aug 29, 2005 20:50 UTC (Mon) by proski (subscriber, #104) [Link] (5 responses)

Could you please give us an example of non-backward-compatible API change in the stable kernel series during the last year? I'm not aware of any.

Linux too please

Posted Aug 29, 2005 20:59 UTC (Mon) by corbet (editor, #1) [Link] (4 responses)

Could you please give us an example of non-backward-compatible API change in the stable kernel series during the last year? I'm not aware of any.

See LWN'a 2.6 API changes page. For starters, the original poster, given the comment, is probably unhappy with changes which break binary modules, and there's been quite a few of those. Source-incompatible changes include the removal of devfs, the USB timeout value units change, the kobject_add() and kobject_del() semantic change (no longer generate hotplug events), the prototype change for kobj_map(), the removal of bcopy(), and the whole pm_message_t change in the PCI subsystem. That's just looking back to 2.6.11, released six months ago.

Linux too please

Posted Aug 29, 2005 21:45 UTC (Mon) by proski (subscriber, #104) [Link]

I don't think 2.6 kernels are considered stable (meaning that the code is changing a lot, not that they don't work well). I'm very well aware of the changes in 2.6 kernels, as I have to update my drivers all the time. 2.6.13 required major changes in PCMCIA drivers (actually, I have to admit partial responsibility for them). On the other hand, 2.4 kernels have stabilized long time ago.

You make a good point about binary compatibility. Indeed, it was never promised by kernel developers, and it can be broken even in 2.0 series. I cannot imagine rpm allowing to upgrade some drivers from 2.4.30 with drivers from 2.4.31 without upgrading the kernel. On the other hand, upgrading some drivers from 2.4.31-1 to 2.4.31-2 should be OK, and thats up to the distributor to ensure.

I can imagine that binary compatibility will be promised for certain kernel series in the future (e.g. 2.4.x, 2.6.x.y) provided that .config is unchanged. But I'm not so optimistic about the main development branch.

After all, changing headers and removing obsolete API is a way to force drivers to change and to adopt a new way of doing things. It's a way to keep the code safe and working the way it should. If a driver doesn't compile, it needs updating.

Linux too please

Posted Aug 29, 2005 21:46 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (2 responses)

There is (userland) API and (in-kernel) API. I understood the former in the grandparent...

Linux too please

Posted Aug 29, 2005 21:51 UTC (Mon) by proski (subscriber, #104) [Link] (1 responses)

Unfortunately, kernel-userland API is irrelevant when we are talking about being able to "update a single driver".

Linux too please

Posted Aug 30, 2005 16:03 UTC (Tue) by obi (guest, #5784) [Link]

I thought we were talking about Xorg here?

Drivers _are_ userland, except for some that use the DRM (mostly for 3D functionality), which isn't distributed/integrated with Xorg but with the kernel.

Which drivers are you referring to exactly?

Linux too please

Posted Aug 29, 2005 21:51 UTC (Mon) by khim (subscriber, #9252) [Link]

If only the kernel hackers could keep the driver API stable for more than five minutes, Linux-based systems could work with a lot more widgets and Linux would be a lot easier concept to sell.

This way lies madness. I'll be frank: it'll reduce number of widgets and make it no better then other OSes.

Why ? Easy: the only way to keep something binary compatible is not change anything. I've seen ennnough drivers broken by Windows Service Packs and/or Solaris upgrades. And in most cases there are no way to use old hardware (and old widgets) with new versions of OS: "Oh, our year-old gadget does not work with your brand-new OS release ? Too bad: buy our super-brand-new gadget+ !".

True: Windows or MacOS aften support new toys better then Linux. But I can use my old toys as long as there are enough users to keep driver in working state - not as long as hardware manufacturer is interested. From my expirience hardware manufacturer attention span are miniscule at best: sometimes even toys one-two years old are unsupported.

And if you still want russian roulette with your drivers... you know where to go, right ?