Linked by Thom Holwerda on Sun 22nd Jul 2007 00:33 UTC, submitted by liquidat
Permalink for comment 257177
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
More News »
Sponsored Links



Member since:
2006-02-07
THIS is a useful API? I looked at the patches; they (1) allow mapping of mmapped-I/O regions to userspace and (2) allow waiting on interrupts. That's it. Useless for anything more complex than a serial port.
Missing interfaces: DMA engines, PCI configuration spaces, fast synchronization primitives, privileged CPU instructions (like disabling of interrupts), fast thread switching (the reason Windows has the graphics subsystem in the kernel - you go 3x slower just leaving the kernel), access to the networking stack, all of this with good performance ... half of these are doable, but several important ones (hint: performance) are flatly impossible outside the kernel. (Smart people have been trying and failing for 40 years, starting with UNIX.)
Oddly enough, this useless API is entirely in keeping with the kernel hacker's thoughts - read Greg K-H's "driver API stability" note and it's quite clear he thinks all drivers do nothing more complex than poke I/O ports and receive interrupts. The 80% of devices that already have GPL drivers are this simple; the other 20% (3D graphics, wireless, and so on) are not.
The API might be useful for embedded devices where describing register layouts is too much information. It is not useful for consumer devices, and it will do nothing to reduce the usage of binary-only drivers.
True, but there are some drivers that do not interface with hardware.