|
|
Subscribe / Log in / New account

Linux too please

Linux too please

Posted Aug 29, 2005 20:50 UTC (Mon) by proski (subscriber, #104)
In reply to: Linux too please by mgb
Parent article: Fedora: RFC: X.Org X11 modularization project - rpm package driver naming

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.


to post comments

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?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds