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

That's why people attempt abstraction

That's why people attempt abstraction

Posted Aug 16, 2011 21:01 UTC (Tue) by michaeljt (subscriber, #39183)
In reply to: That's why people attempt abstraction by djbw
Parent article: Avoiding the OS abstraction trap

> 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.


(Log in to post comments)

That's why people attempt abstraction

Posted Aug 16, 2011 21:05 UTC (Tue) by dlang (subscriber, #313) [Link]

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

Posted Aug 18, 2011 20:34 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> 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.


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