Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
That's why people attempt abstraction
Posted Aug 12, 2011 22:54 UTC (Fri) by JoeBuck (subscriber, #2330)
Posted Aug 12, 2011 23:27 UTC (Fri) by djbw (subscriber, #78104)
Posted Aug 13, 2011 3:00 UTC (Sat) by quotemstr (subscriber, #45331)
Posted Aug 13, 2011 3:14 UTC (Sat) by mjg59 (subscriber, #23239)
So it depends. If you want to do nothing but run 3D applications then their approach is successful, and if you want to do anything else their approach is dreadful.
Posted Aug 14, 2011 19:16 UTC (Sun) by mlankhorst (subscriber, #52260)
Posted Aug 13, 2011 19:18 UTC (Sat) by cpeterso (guest, #305)
The abstraction layers described in the article sound like they are focused on implementation details instead of capturing a higher-level "domain model". Admittedly, designing a platform-independent domain model for a kernel driver manipulating hardware sounds challenging.
Posted Aug 16, 2011 21:01 UTC (Tue) by michaeljt (subscriber, #39183)
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.
Posted Aug 16, 2011 21:05 UTC (Tue) by dlang (✭ supporter ✭, #313)
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.
Posted Aug 18, 2011 20:34 UTC (Thu) by michaeljt (subscriber, #39183)
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.
Posted Aug 13, 2011 11:44 UTC (Sat) by justincormack (subscriber, #70439)
Posted Aug 13, 2011 12:42 UTC (Sat) by ftc (subscriber, #2378)
Posted Aug 15, 2011 20:08 UTC (Mon) by wilck (subscriber, #29844)
Posted Aug 15, 2011 4:04 UTC (Mon) by broonie (subscriber, #7078)
Avoiding the OS abstraction trap
Posted Aug 13, 2011 9:24 UTC (Sat) by intgr (subscriber, #39733)
So instead of one 60kLOC driver, they would now have three 20kLOC drivers. I'm not sure that's a bad thing.
Posted Aug 14, 2011 2:12 UTC (Sun) by JoeBuck (subscriber, #2330)
Posted Aug 14, 2011 11:31 UTC (Sun) by ebirdie (subscriber, #512)
On Linux there is no need to maintain any Kloc for isc driver, if the initial driver development is done the "Linux community way", ie. shared, until the hardware will get revisions, which may need new bits and pieces added in by the vendor development team.
To put it another way with over simplification and has a familiar sound. Write once and forget. ;-)
Posted Aug 14, 2011 16:01 UTC (Sun) by bfields (subscriber, #19510)
We certainly hope contributors can reduce their maintenance load, but if we lead them to expect it to be reduced to zero, then we risk ending up with a lot of bit-rotted drivers.
Posted Aug 15, 2011 16:38 UTC (Mon) by misiu_mp (guest, #41936)
Posted Aug 16, 2011 6:20 UTC (Tue) by ebirdie (subscriber, #512)
I love this, because to me it implies that the piece of hardware (ie. a chip and its surrounding implementation) has better chances to shine on its own as hardware and not leveled to other similar hardware just by a software development method, which does not directly produce any good to me.
Posted Aug 15, 2011 9:08 UTC (Mon) by linusw (subscriber, #40300)
So writing three different device drivers tailored for three differen OS:es isn't necessarily that bad, as long as you have people who are actually comfortable with diving around all three codebases and making sure the know-how about the hardware is shared between all three codebases.
The key assumption I do is that if a developer is to focus on one technical aspect at a time across several codebase rather than one specific codebase across several technical aspects at a time, the outcome may be better.
This may be true to varying extent in different contexts, it's just my intuitive feeling.
Posted Aug 15, 2011 17:14 UTC (Mon) by misiu_mp (guest, #41936)
There is much more people with kernel knowledge than a with particular hardware knowledge. A well documented driver written in a language that is easy to understand to kernel hackers will widen the potential circle of hardware knowledgeable people. Once the know-how is out there or easy to reach, the writing is a formality.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds