LWN: Comments on "Avoiding the OS abstraction trap"

OS abstraction - not always a trap

dlang — Sun, 02 Oct 2011 00:39:57 +0000

I'll also point out that there are a lot of people who don't see binary blobs that are not executed on the main CPU as being any problem

OS abstraction - not always a trap

Duncan — Sat, 01 Oct 2011 09:48:12 +0000

> Every one of them has given a license to anyone who chooses to use it that is described in its entirety by one document: GPL V2.

AFAIK, the GPLv2 describes the collected work, and individual files/patches must of course have compatible licenses, but no, the GPLv2 does not describe "in its entirety" the license of every individual part, as some parts are more liberally licensed (2-Clause BSD, LGPLv2, GPLv2 or later instead of specific v2 as applies to the kernel as a whole, etc.).

Additionally, I do not believe the GPLv2 describing the license "in its entirety" is fully correct for even the kernel as a whole, due to Linus's specific waiver of the "derived work" claim for userspace as opposed to kernelspace, or as specifically worded in the kernel's GPLv2 preamble in the COPYING file, "user programs that use kernel services by normal system calls".

FWIW, your statement might have been "loosely acceptable" if not entirely accurate, had it not used the words "in its entirety", but it's clearly incorrect with the inclusion of the "entirety" claim, because that claim is clearly factually incorrect.

Finally, there's the various binary firmware blobs, some of which are still in the kernel, which don't really comply with the GPLv2 at all, and which make a lot of people nervous. However, they're gradually being moved out of the kernel, there's various "deblobbed" kernel sources available, and should someone legally force the issue, it's now to the point where they could be stripped and packaged separately with, probably less technical disturbance than for instance the switch to the two-digit kernel 3.0 numbering scheme caused... which might be why nobody's bothered asserting legal claim to force the issue, since it's hardly worth it now and the separation is gradually happening on its own anyway.

Meanwhile, just in case someone gets the wrong idea... I'm not a lawyer, nor do I even pretend to play one, anywhere. However, it's not like this actually requires a lawyer to see, since the waiver's clearly there in the COPYING file, individual files clearly carry their own various licenses, and the firmware issues are well known.

Not that many will likely read this, over a month after original publication of the parent article, but there's always the few coming in via Google, or following links in later LWN articles referring back to this one.

Duncan

OS abstraction - not always a trap

slashdot — Fri, 26 Aug 2011 14:50:35 +0000

A much simpler solution is to code the driver to the Linux interface, and implement the parts of it that are used for Windows and OSX as well.

kloc

dlang — Thu, 25 Aug 2011 04:41:30 +0000

when was the last time anyone found a million lines of dead code in the kernel (like what was removed by libreoffice from the openoffice.org codebase)

how many of the 'easy' office suites that existed 10-20 years ago are still in use today?

kloc

chloe_zen — Thu, 25 Aug 2011 00:31:49 +0000

Let us also consider the possibility that more effort per kloc means they're working harder to make better code.

Writing big code is easy! Writing small yet good code is much harder.

Avoiding the OS abstraction trap

chloe_zen — Thu, 25 Aug 2011 00:25:42 +0000

To claim that the current kernel development model means less resources is a fallacy. Compared to other open source projects of similar size (KDE, GNOME, Mozilla, LibreOffice), the Linux kernel involves around 10 times more developers per kloc.

I don't know if that statistic is correct, but if it is, I'd attribute that to the difficulty of developing a kernel vs. developing an application. I've done both, at least a bit -- I identified and fixed an SMP-specific dentry race condition in NFS, and wrote the boot-time DHCP support -- so I'm not just guessing.

From The Tao of Programming, 3.3:

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer, "when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
The programmer made no reply.

This is are totally different issues...

Np237 — Sun, 21 Aug 2011 18:37:24 +0000

Yup, you point out the very problem. Once you care about speed (and at work, we do, a lot), youre basically screwed. Youre forced to buy nVidia since they are the only ones with fast Linux drivers, and you get a shitload of bugs and no support for modern desktops.

I'm not talking about bugs...

khim — Sun, 21 Aug 2011 08:19:37 +0000

A lot of drivers contain workarounds for buggy hardware. I'm not talking about these. I'm talking about the fact that each new generation of GPU chips have totally different initialization sequences and even basic operations often require totally different driver.

AFAIK videodrivers are more-or-less unique in this regard. 802.11n WiFi card have driver almost identical to what 801.11b had - even if chip internals are wildly different. Yes, I know, GPUs are significantly more complicated... well, they are not more complicated then CPUs and these can reuse older software just fine. About the only piece of silicone comparably buggy were winmodems - and these, too, were brought to life by the promise to paper over hardware problems in software.

OS abstraction - not always a trap

giraffedata — Sat, 20 Aug 2011 21:01:12 +0000

And they have also made it clear that a "portable" version of the driver would not be the preferred form. So, where's the problem?

How have they made that clear?

Every one of them has given a license to anyone who chooses to use it that is described in its entirety by one document: GPL V2. That document gives no detail at all on what "the preferred form of the work for making modifications to it" is.

And incidentally, if one of the kernel authors did decide to be more specific, he'd be violating some previous author's copyright, because of GPL's condition that one offer one's own additions under GPL.

OS abstraction - not always a trap

BenHutchings — Sat, 20 Aug 2011 19:34:17 +0000

The owners of that have authorized folks to prepare and distribute derivative works only if they provide their source code in "preferred form."

And they have also made it clear that a "portable" version of the driver would not be the preferred form. So, where's the problem?

This is are totally different issues...

BenHutchings — Sat, 20 Aug 2011 19:30:18 +0000

This means that decisions like "save 0.01% of transistor budged and fix all the crap in drivers" look viable.

The decision is more likely "don't delay tape-out to fix this hardware bug". And it has nothing to do with the ability to hide the workarounds in a proprietary driver. Like programs, all chips have bugs, and you can see workarounds for them in almost any Linux driver you care to look at.

This is are totally different issues...

khim — Sat, 20 Aug 2011 10:07:10 +0000

And for years (2004-2008) I used ndiswrapper and the WINDOWS wireless driver for my laptop because the Linux drivers either didn't work, crashed, broke suspend or changed their behavior. This seemed to vary with each kernel release.

Yup, but this period stretched for so long because "use the ndiswrapper" was standard answer and thus native drivers were poorly tested and few developers spent time fixing them. This is obvious trade-off: stable ABI makes life easier for user short-term but does not improve situation all that much long term, yet it makes life of developers miserable both short term and long term... and kernel developers rarely accept any decision which promise tiny short-term relief at the price of huge long-term pain. That's why Linux is still around and a lot of other OSes are not.

It needs dozens of developers who analyze OpenGL use by software and determine how to optimize the code.

I can't care less about "optimized code paths". The fact that all these complex and fragile compilers are in driver is madness. They don't belong there! Just like format converters for webcams don't belong there. The problems with drivers I do care about are things the driver should do: setup the videomode, handle DMA, etc. And there are two problems with these needs:
1. There are no documentation: AMD's is probably the best, Intel is slightly worse, NVidia does not have anything.
2. These sequences are changing between releases (and sometimes between steppings) for no good reason.

Note that problem #2 is significantly worse and it's brought to light entirely because Windows offers stable ABI for driver writers. This means that decisions like "save 0.01% of transistor budged and fix all the crap in drivers" look viable. This then leads to problems in both Windows and Linux, but as long as thing more-or-less works in Windows chip can be sold.

If you want to match Nvidia binary drivers, you have to do those things. It's expensive. Really expensive.

It's not hard to match NVidia driver's quality. They may offer fast 3D in games - but I don't care about that. I do care about silly things like suspend, thermal monitoring, etc - and there NVidia drivers are awful. Open-source drivers are better in this regard - but just barely, they still are awful, nothing like [currently quite stable] WiFi drivers.

OS abstraction - not always a trap

giraffedata — Fri, 19 Aug 2011 22:11:25 +0000

Which could be defended against with estoppel because the generation of the kernel code and then labelling it as GPL was done by the copyright owner.

Wrong code. We're talking about the copyright on the rest of the kernel. The owners of that have authorized folks to prepare and distribute derivative works only if they provide their source code in "preferred form." So if the generated code isn't preferred form, and a copyright owner gets nasty, there could be trouble both for the authors of the asihpi driver and anyone who distributes a kernel that contains it.

It exists in its own right independent of our private version. The scripted conversion just saves us the process of porting changes manually when our version changes.

Note that you could say the same thing about an ELF version which the author compiles from C, and everyone agrees ELF is not "the preferred form."

The fact that the generated code is C, and presumably pretty normal C, is a much more persuasive argument that it is "the preferred form."

I guess the answer is irrelevant until the copyright owner of the code in question decides to turn nasty.

I don't see how this is possible once the code has been released under GPL.

First, to be clear: "the code in question" is the Linux kernel in its entirety. And if the asihpi driver code is not in the preferred form, then the code in question has not been released - its release was conditional on everything lumped with it being available in preferred form.

If you tried irony then you failed. Utterly and completely.

zlynx — Fri, 19 Aug 2011 22:06:16 +0000

Yeah.

And for years (2004-2008) I used ndiswrapper and the WINDOWS wireless driver for my laptop because the Linux drivers either didn't work, crashed, broke suspend or changed their behavior. This seemed to vary with each kernel release.

As for the open source video drivers, for most of them I don't believe the problem is vendors hurting the effort. AMD and Intel have been supportive. I believe the problem is just not enough resources.

It needs a massive test effort that will verify correctness in all major OpenGL applications on each card version. It needs exhaustive OpenGL test suites that exercise all the code paths. That's a hundred test machines right there.

It needs dozens of developers who analyze OpenGL use by software and determine how to optimize the code. The commercial drivers often have optimized code paths for specific applications.

If you want to match Nvidia binary drivers, you have to do those things. It's expensive. Really expensive.

OS abstraction - not always a trap

Eliot — Fri, 19 Aug 2011 02:28:39 +0000

>Interesting... I briefly looked at COG (http://nedbatchelder.com/code/cog/) >when I was still in the "maintain the abstraction" stance. But it was >ultimately untenable. I can not speak to sound drivers, but for isci it >needs to inter-operate with libata, libsas/sas transport class, and the >rest of the scsi midlayer. Duplicating all those common definitions was a >big problem. Redoing work that an upper layer had already handled was >another item. General non-idiomatic expressions and code organization got >in the way...

For the driver I refer to, the majority of it is 'below' alsa midlayer, and handles the detailed interface to the hardware. There is one alsa-specific file that uses APIs provided by our shared code.
Sometimes this does get in the way, and the driver may slowly change to cut out the middle-man, but meanwhile, it is still usable.

And yes, I'm familiar with COG. We use it a bit, but not for this purpose.

OS abstraction - not always a trap

Eliot — Fri, 19 Aug 2011 02:22:14 +0000

>> Does this mean that the version distributed on kernel.org and by other distributors is not the "preferred form of modification"?

> Apparently not.

Of course it is the "preferred form" for anybody working with the kernel sources. It exists in its own right independent of our private version. The scripted conversion just saves us the process of porting changes manually when our version changes.
(note that the 'original' sources are also available under GPL licence)

There is no sign of anyone else trying to submit other than very minor patches to this code. If that happens we'll have to work out what to do...

> (For most hackers, the "preferred form of modification" would actually be a cloned git tree.)

>> I guess the answer is irrelevant until the copyright owner of the code in question decides to turn nasty.

I don't see how this is possible once the code has been released under GPL.

OS abstraction - not always a trap

djbw — Thu, 18 Aug 2011 21:24:14 +0000

Interesting... I briefly looked at COG (http://nedbatchelder.com/code/cog/) when I was still in the "maintain the abstraction" stance. But it was ultimately untenable. I can not speak to sound drivers, but for isci it needs to inter-operate with libata, libsas/sas transport class, and the rest of the scsi midlayer. Duplicating all those common definitions was a big problem. Redoing work that an upper layer had already handled was another item. General non-idiomatic expressions and code organization got in the way...

That's why people attempt abstraction

mjthayer — Thu, 18 Aug 2011 20:34:00 +0000

> there is already code in the kernel that is primarily developed and maintained elsewhere.
>
> however, the kernel developers don't feel much need to respect the idea of 'this code is read-only on kernel.org', if they make an interface change in the kernel, they will make that change even on these drivers that have their 'primary source' external to the kernel, and it's up to that external source to pick up the changes so that they don't break with the next merge request.

I suppose the easiest way around that would be to make sure that the code parts which are "kernel-external" only interface to other parts in the driver, and not to anything outside. Without letting those other parts become too much of a simple abstraction layer, see above. Another problem that I see though is coding style - having code shared between the kernel and something else in this way forces that something else to adopt the kernel coding style, which is likely not to be the same as their preferred style.

OS abstraction - not always a trap

vonbrand — Thu, 18 Aug 2011 19:08:04 +0000

I shudder contemplating the maintenance of said "scary sed/Python/whatever" scripts, keeping up with Linux changes.

Avoiding the OS abstraction trap

rgmoore — Thu, 18 Aug 2011 18:44:19 +0000

What you are describing is not the solution, it is the problem.

I'm pretty sure the kernel maintainers would disagree violently; they would say the problem is the existence of out of tree drivers. They have said on numerous occasions that they are happy to write their own drivers for any hardware manufacturer that is willing to provide the documentation necessary to write it. If you want them to share their kernel code but don't want to return the favor by sharing your driver code, you have no standing to turn around and demand they change their development process to make your life easier.

What "other popular operating systems" are you talking about?

khim — Thu, 18 Aug 2011 16:26:39 +0000

If you are talking about Windows then it's unmitigated disaster: drivers voodoo is huge part of that culture - and it only exist because neither users not hardware vendors can abandon this crazy platform. It's because it has a monopoly and a lot of softwate only work under window - not because it's such a fun to use. Often drivers only work for one particilar version of OS (Windows 98 or XP or whatever), and even then they are huge PITA.

And all other platforms have died for the lack of drivers: such diverse OSes and Solaris, Symbian and many many others were abandoned and replaced with Linux because Linux has the most drivers available.

Think Android: it's brand-new OS and we all know Google does not like GPL - yet it uses Linux, not NetBSD or something like that. Why? Because they needed "bag of drivers" and Linux was the only sane choice.

Or think RIM. They have choosen to switch to QNX. Well, QNX is good OS, but it does use your favored "stable ABI" drivers model... and suprisingly enough this means it does not have as many drivers as Linux and the ones they do have are often worse. This means RIM's hardware selection is limited and that means RIM is already dead: it's question of "when", not question of "if".

If you tried irony then you failed. Utterly and completely.

khim — Thu, 18 Aug 2011 16:11:22 +0000

WiFi is actually pretty good example. We used to have bunch of crappy WiFi drivers but they were mostly abandoned and replaced.

As for videodrivers... well, the vendors decided that they absolutely, positively need to produce crap - and that's why videodrivers are crappiest drivers on all platform. I think open-source drivers eventually will fix the problem but this process is slow-going because most vendors are not just indifferent - they actively hurt these efforts.

This is the problem, not a solution...

fuhchee — Thu, 18 Aug 2011 15:47:48 +0000

"Yeah, "more crappy drivers" is real problem" ...

You are misparaphrasing me. Mediocre/working can be good enough for users. There exist other popular operating systems that demonstrate this quite well.

This is the problem, not a solution...

Np237 — Thu, 18 Aug 2011 15:47:02 +0000

Of course, this is why we have such excellent drivers for wi-fi and graphics cards and the ones with crappy drivers have all been abandoned.

Wait

This is the problem, not a solution...

khim — Thu, 18 Aug 2011 15:43:25 +0000

Yeah, "more crappy drivers" is real problem, and unstable ABI solves this problem quite handily, so what are the advantages?

It's actually better not to have any drivers rather then have crappy drivers - not just long-term, but also a medium-term. If there are no drivers then someone will write them or hardware will just be abandoned, but crappy drivers make user's life miserable for a long, long time.

Avoiding the OS abstraction trap

josh — Thu, 18 Aug 2011 15:06:42 +0000

The process tends to go much more smoothly if the developers start working with upstream sooner than the pointer where they have a full cross-platform abstraction-layer-based driver. Among other things, it means the platform can get fixed sooner, the driver workarounds never need to get written, and the development doesn't need to happen twice.

Talk to the kernel community during the design phase, not during the 'it's "done", please merge' phase.

OS abstraction - not always a trap

cladisch — Thu, 18 Aug 2011 14:32:50 +0000

> Does this mean that the version distributed on kernel.org and by other distributors is not the "preferred form of modification"?

Apparently not.

(For most hackers, the "preferred form of modification" would actually be a cloned git tree.)

> I guess the answer is irrelevant until the copyright owner of the code in question decides to turn nasty.

Which could be defended against with estoppel because the generation of the kernel code and then labelling it as GPL was done by the copyright owner.

OS abstraction - not always a trap

cortana — Thu, 18 Aug 2011 11:42:16 +0000

Does this mean that the version distributed on kernel.org and by other distributors is not the "preferred form of modification"?

I guess the answer is irrelevant until the copyright owner of the code in question decides to turn nasty.

Avoiding the OS abstraction trap

fuhchee — Thu, 18 Aug 2011 10:26:35 +0000

"But what do they get in return?"

Perhaps more drivers from companies who cannot afford to chase upstream, but who'd be willing to produce mediocre/working ones for a stabler API.

Avoiding the OS abstraction trap

dmag — Thu, 18 Aug 2011 09:56:20 +0000

> To claim that the current kernel development model means less resources is a fallacy.

Well, I guess I (and the kernel developers) agree to disagree.

> Compared to other open source projects of similar size (KDE, GNOME, Mozilla, LibreOffice)

It's not news that an Operating System Kernel requires more work than a Word Processor or a Browser. Want to bet that Linux supports more CPU architectures than your Word Processor supports file formats?

> Every time you rewrite the SATA stack or the USB one, it involves an insane amount of work to update every single driver.

Heh. It only looks that way on TV. Real programmers write programs to do the programming for them.

http://lwn.net/Articles/315686/

> Theres also a world out there where computers need to just work and to do the same thing for decades.

Exactly. That's the job of the distributors. They fork the kernel and support it for as long as people will pay for it.

Avoiding the OS abstraction trap

Np237 — Thu, 18 Aug 2011 09:27:53 +0000

To claim that the current kernel development model means less resources is a fallacy. Compared to other open source projects of similar size (KDE, GNOME, Mozilla, LibreOffice), the Linux kernel involves around 10 times more developers per kloc. The very reason for requiring so much people is that the current model IS the burden. Every time you rewrite the SATA stack or the USB one, it involves an insane amount of work to update every single driver.

1 year is too long in your book? Sorry, but thats nice of you for living in a pure-developer world where you can break everything every 2 weeks. Theres also a world out there where computers need to just work, and to do the same thing for decades.

Avoiding the OS abstraction trap

dmag — Thu, 18 Aug 2011 09:14:42 +0000

> Many large-scale open source projects have found elegant solutions to similar problems

Most plug-in APIs (like browser plug-ins) have a small 'surface area'. This is not true with kernel drivers. There is a massive number of internal APIs/datastructures. Trying to keep back-compatibility would slow development.

For example, if the kernel would be faster if we eliminated the "jiffies" variable, should we delay that change because someone somewhere _may_ have a proprietary driver that _might_ use it?

> They let several APIs coexist for reasonable timeframes

Either you refactor the API or you don't. If your code is required to be back-compatible for some time, then you can't _really_ refactor your code. You can only "create a new API, shuffle things around a little bit." You are in a straight jacket and prevented from making radical simplifying changes.

> forcing people to migrate to new APIs after 1 or 2 years.

That implies forcing people to keep their radical patches for 1 or 2 years.

> Im not asking for refactorings to wait for 3 years.

Well, you just said 2. Even 1 year is too long in my book.

> I fail to see in what way the kernel would need to be different.

If an internal API is deemed to be defective, you are saying it would have to be supported for years. Today, it is simply deleted and rewritten, so the defective API can no longer cause problems. Much simpler, no maintenance burden. (For examples, see read the excellent articles here on how the RCU API has changed thru the years.)

You're asking the kernel developers to take on a *lot* more maintenance burden. But what do they get in return?

OS abstraction - not always a trap

Np237 — Thu, 18 Aug 2011 07:55:35 +0000

What you describe makes me feel positively sure that it would be less costly to maintain the 3 drivers separately.

Avoiding the OS abstraction trap

Np237 — Thu, 18 Aug 2011 07:53:52 +0000

What you are describing is not the solution, it is the problem.

Many large-scale open source projects have found elegant solutions to similar problems. They let several APIs coexist for reasonable timeframes, phasing out unneeded ones and forcing people to migrate to new APIs after 1 or 2 years. I fail to see in what way the kernel would need to be different.

Said otherwise, Im not asking for refactorings to wait for 3 years. Im asking that they wait 6 months and get done cleanly.

OS abstraction - not always a trap

Eliot — Thu, 18 Aug 2011 02:07:53 +0000

Can I provide a counter example?
The ALSA asihpi driver is about 90% shared code with osx and windows drivers.

The private source is transformed by (scary) sed and python scripts into
the public version visible in the kernel.
Part of this process replaces OS-abstraction wrappers with their equivalent kernel direct calls. Datatypes and symbol names are also transformed to
kernel style. Other-OS-specific ifdef blocks are removed using a simplified preprocessor.

The result is not particularly pretty, but it allows the driver to exist by minimizing the linux-sepcific development and maintenance. It is much less likely that this driver would exist if the entire thing had to be rewritten and maintained separately.

Avoiding the OS abstraction trap

dmag — Thu, 18 Aug 2011 01:56:20 +0000

> I dont mean that we should stop changing these APIs. But we should do so over larger timeframes and with a clear roadmap.

The 2.4 kernel series tried to do what you propose: Many large, invasive patches were put off until later. Developers hand to carry their patches around for years. Then, when 'later' came, there was much pain trying to stabilize many massive changes at once.

So during 2.6, they decided to optimize for kernel developers, not anonymous 3rd parties who aren't maintaining the kernel. Patches were integrated when they were ready, instead of some artificial deadline. The USB API was rewritten to make drivers easier to write. The network API was rewritten to allow switching interrupts to polling during high loads (saving a lot of CPU when it's needed most.) A suspend/resume API was globally added to every driver. New APIs are created to better abstract memory management (especially under memory pressure). etc, etc, etc.

Huge swaths of the kernel are rewritten constantly, including internal "driver APIs".

> rewrite large stacks without any care for the consequences on out-of-tree drivers.

Be careful what you wish for. This is what economists call an externality.

The kernel developers want to refactor kernel code globally (without worrying about making all data structures and APIs back-compatible, which would take a lot of extra work.)

The 3rd parties (with outside code) want a stable API so they can do less work of trying to keep up with the changes in the kernel. The 3rd parties wouldn't pay any of the costs, since they (generally) aren't core kernel maintainers. The 3rd parties would literally choose to slow kernel development in order to make their lives easier.

Luckily, 3rd parties don't get to make the choice, the kernel developers do.

That's why people attempt abstraction

dlang — Tue, 16 Aug 2011 21:05:59 +0000

there is already code in the kernel that is primarily developed and maintained elsewhere.

however, the kernel developers don't feel much need to respect the idea of 'this code is read-only on kernel.org', if they make an interface change in the kernel, they will make that change even on these drivers that have their 'primary source' external to the kernel, and it's up to that external source to pick up the changes so that they don't break with the next merge request.

That's why people attempt abstraction

mjthayer — Tue, 16 Aug 2011 21:01:37 +0000

> Teams can collaborate and maybe find some highest-common-factor code to share, but at the end of day each environment has it nuances that need special attention. The cost of getting the abstraction wrong is high, the chance of getting abstractions layers right is low (for non-trivial drivers).

I could potentially imagine the review process of an "abstraction layer-based driver" going along the lines of "this abstraction is acceptable, this one is not, this one could be acceptable if it were changed a bit". You might then end up with things like some code which is generic for all other supported OSes (or most other? You might find that one or two other target OSes also benefit from having their own implementations) being re-implemented for Linux, but still keep your somewhat refactored core code OS-independent. And of course, like the Linux kernel API, your abstraction layer need not be set in stone and "right the first time". It can be refactored as problems are found or new needs appear.

I wonder though more generally whether it would be acceptable to the Linux kernel community to have code files in the kernel for which kernel.org is not the "primary" site? Otherwise there is little chance of a driver in the upstream kernel having any sort of shared core with other OSes.

Avoiding the OS abstraction trap

Np237 — Tue, 16 Aug 2011 08:27:25 +0000

OS abstraction is indeed a bad idea, and one that doesnt depend on the involved OSes.

But in the issues described in this article, some are caused by OS abstraction, and others were caused by the stable API nonsense fallacy, which is a Linux-specific problem. Not having any kind of stable kernel interface makes it harder for device driver developers to work on their driver. Instead they have to work on the kernel itself, coping with its ever-changing needs to update their work instead of improving it.

I dont mean that we should stop changing these APIs. But we should do so over larger timeframes and with a clear roadmap. Currently its just a giant mess and anyone can decide to rewrite large stacks without any care for the consequences on out-of-tree drivers.

Avoiding the OS abstraction trap

Np237 — Tue, 16 Aug 2011 08:20:13 +0000

As long as these patches are useful additions or real bug fixes (which the acceptance guidelines should guarantee), this is not gaming the system. Quite the opposite actually, it means giving more incentive to improve the system.