A Stable Linux Kernel API/ABI? "The Most Insane Proposal" For Linux Development

[phoronix]

Phoronix: A Stable Linux Kernel API/ABI? "The Most Insane Proposal" For Linux Development

For some lighthearted weekend reading and sure to make for some interesting discussions in the forums is what was volleyed today onto the kernel mailing list: "The most insane proposal in regard to the Linux kernel development." It's about shaking up the way the Linux kernel development happens, but almost surely the proposal won't end up resulting in changes...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Stable-API-ABI

[SpyroRyder]

Bookmarking a link to that thread, even if it remains civilish it'll still be worth the read

[Delgarde]

Bookmarking a link to that thread, even if it remains civilish it'll still be worth the read

"Please share your opinion", he says. Yeah, that should make for interesting reading. The proposal does have some merit, but it's also absolute anathema to the kernel developers... it creates a whole lot of extra overhead for them, which never goes down well.

[Idonotexist]

Within Linux's own source code is documentation that explains why this will never happen, in a file called Documentation/stable_api_nonsense.txt . Have a read. Not that I necessarily agree with what's being said. Linux definitely would have more drivers if it had stable interfaces, but they would be closed-source, and Linus is philosophically against policies that most benefit companies that want to keep their drivers closed-source. He doesn't want more drivers if they're just going to be closed-source. It's a political and a philosophical choice, and a respectable one at that.

[mlau]

Linux definitely would have more drivers if it had stable interfaces

That may have been true a long time ago, but no longer.
Linux' hardware support out of the box is pretty good. And the omission of a stable API/ABI for kernel drivers makes it easier to identify and generalize code commonly duplicated by drivers or fix bugs in them. If it turns out that there is e.g. a better/more efficient way to do something, all drivers are converted at once. With that stable ABI
nonsense you'd have to keep a copy of the old way for ABI users around.

I'm sure that noone is going to stop this guy from creating a fork that implements just that, but I'm not so sure that he'd be able to keep up with identifying
and backporting bugfixes to his stable ABI drivers.

[Min1123]

I've often thought this would be a great idea, because it seems like it would imply less churn on drivers, and an easier approach to creating the drivers as well. Since I've been playing with ARM SBCs though, I've determined that API/ABI is not really the charge that should be led at this time.

ARM SBCs rely on ARM SoCs, and depending upon the SoC and whatever hardware the manufacturer scraped together, you end up with entirely different versions of things constantly. I feel that Google did a great disservice to the Linux community when they tried to make sense of the Linux kernel for their Android OS, in that they made a specific fork of the kernel, and then encouraged others to make forks of that fork and pile ugly patches on it to get their hardware to work. This methodology (I believe) came out of the Linux communities attitudes towards hardware and drivers which is outdated compared to the constant onslaught of new hardware. When Linux was created, PCs had generalized parts from a variety of manufacturers that were compatible with each other because they were emulating an earlier device hardware spec through cloning the spec. So you had SVGA cards that all dealt with the VESA specifications and all had a BIOS that started up and was used in a particular way. So Linux supported VESA and could always open up the framebuffer for all of those cards, same for IDE, ATAPI, Serial and Parallel ports. No such common beasts on modern non-PC computing platforms. So I end up with a bunch of forks of u-boot and a bunch of forks of Linux that have been so bastardized they can't operate with anything else, and there is nothing in my power, or that of the upstream kernel, to support what they did. Linux has made it hard to get support for drivers and platforms because of extremely high standards of coding. That is not a bad thing, but electricity flows the path of least resistance and so have these forks. If it would be difficult to make a correct patch for Linux, just fork Android Linux and cram whatever you need to get it booting in there, publish, profit.

My suggestion, is to leverage one of the great capabilities of GIT, submodules, and split the kernel tree. Take the drivers and make them separate. That way you have the base kernel, the subsystems for the kernel, the busses (PCI,USB,Maple), the filesystems, the networking, the specific device drivers.

If you can split these out and get people to only change the area they need to in order to support their devices, there just might be a chance of preventing this constant incompatible forking situation from actually becoming the norm.

[tessio]

Don't Red Hat do something like that? They maintain a stable kernel, and backports updates from the new ones..

[V10lator]

Either you use a stable distro which has quite an outdated kernel release which might not support your hardware or you run the most recent stable version but you lose stability and you are prone to regressions. This problem can be solved by decoupling drivers from the kernel and supplying them separately so that you could enjoy stable kernel version X with brand new drivers

Wait, what? That guy want to workaround bleeding edge drivers by using bleeding edge drivers coupled with stable ABIs? That doesn't make much sense to me.

like it's done in most other proprietary OS'es

Is he saying Linux is a proprietary OS or did he get the point that what's good for proprietary don't have to be good for open source, too?

unstable kernel APIs should be developed in parallel to stable APIs

So drivers will use the more featured, unstable APIs and the stable APIs will rust in dust (or Android will be very happy).

after its release six years later, hardware vendors had to support just two kernel releases. Not that is a big issue.

Just a wild guess but there might be drivers in the kernel which are older than 6 years but not touched by hardware vendors...

so radical changes which warrant new kernel API/ABI are less likely to be introduced.

So there's no problem and nothing needs to be changed?

Seriously, this guy confuses me on so many levels.

[DeepDayze]

Don't Red Hat do something like that? They maintain a stable kernel, and backports updates from the new ones..

I am sure they do, as Red Hat Linux is primarily used for servers where a stable environment is generally required. Having a relatively stable API/ABI makes for less maintenance work needed as well as keeping compatibility with applications and drivers.

[bitman]

What does this solve at all... Tackling fragmentation of linux distributions would be nice. Never had much issues with kernel breaking compatibility. Sure some drivers break here and there. Sure i had nvidia drivers stop working. I certainly had to patch vmware drivers to compile for new kernel. And yet its really no big deal when we are dealing with trainwreck of userspace we have now. So yeah, time better spent elsewhere..