User: Password:
|
|
Subscribe / Log in / New account

Avoiding the OS abstraction trap

Avoiding the OS abstraction trap

Posted Aug 16, 2011 7:32 UTC (Tue) by wilck (guest, #29844)
Parent article: Avoiding the OS abstraction trap

Dan, it is interesting to see you fully take the kernel maintainers' point of view, assuming that you're mainly paid for being a driver developer. But there's a back side of the coin, too.

Am I mistaken assuming that OS abstraction would have worked for your driver for all OSes except Linux? The technical problems you describe look valid, but they could have been solved with a few simple macros (the phys_to_virt() example was caused not by abstraction per se, but by using an oversimplified abstraction caused by coding for some other OS first).

What really matters here is not the technical reasons but the political ones. The maintainers don't like common code, compatibility layers and such. They don't care that you need to develop your driver for several OSes and several flavours of Linux. They want you to write the leanest possible code and if possible, do it in a general way that fixes problems or implements features in the entire subsystem you're working with. That's of course also an abstraction which causes further complexity for you, but this time the community benefits, so this kind of abstraction is not only welcome, it also helps you earn credit points.

You could have opted to develop your driver off-tree and focus on support for the main (enterprise) distribution kernels. You decided to be a good Linux citizen and buy into the 'Develop In Tree, Stable API Is Nonsense' doctrine. If I am reading correctly, the upstream acceptance process cost your group almost 6 months of work. The result is a leaner driver, but I assume that the common code base still exists (after all, the code for the other OSes needs to be maintained as well), so what you now have is the old code plus the new one, and the duty to maintain both.

In order to get your device actually supported for customers, you need to do back-porting to distribution kernels. I suspect that solving "platform problems" in upstream subsystems benefits you little for that task, with the OS kernels still including the old broken subsystem code. What do you do - try to convince distributions to pull in the modified subsystems, re-enable the former workarounds you made in your driver, or not support certain distributions at all?

You are in the lucky situation that your employer understands and accepts the development rules the community decreed. Other companies may see things differently. Your article illustrates beautifully that, contrary to common Linux myth, it's harder and takes longer to get a device supported under (upstream) Linux than on other platforms. Apart from having to adopt the kernels' development paradigm, it also requires a social exercise and lengthy trust-and-credit-earning process. You seem to have a boss who is willing to pay for that. Good for you.


(Log in to post comments)

Avoiding the OS abstraction trap

Posted Aug 18, 2011 15:06 UTC (Thu) by josh (subscriber, #17465) [Link]

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.


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