Linked by Thom Holwerda on Mon 17th Sep 2012 16:56 UTC, submitted by Andy McLaughlin
Thread beginning with comment 535712
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Features
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
Linked by Thom Holwerda on 04/14/13 18:22 UTC, submitted by MOS6510
More Features »
Sponsored Links



Member since:
2011-01-28
Brendan,
We're talking over one another. I keep hearing that this wouldn't become widespread and manufacturers wouldn't get involved, etc, but we've established this already and I've been saying it explicitly from the start. Without cooperation from the top corporations, this would not succeed. It would most likely have the same fate as UDI.
I'm just talking about how it should be.
"A driver is a kind of abstraction layer between whatever interface the OS wants and whatever interface the hardware provides. What you're talking about is having drivers that provide an unwanted interface, with a 'driver driver' between the unwanted interface and the OS itself."
I think if you talked to most OS developers you'd find that drivers are by far the most difficult problem to address (Andy McLaughlin said the same thing in the interview). This would be something they want very much. It'd be extremely desirable to support all hardware by implementing one interface.
Linux users might view it as a non-issue because linux is actually big enough to have manufacturers and tons of volunteers working on it's drivers. But even then we'd save a lot of work and reduce tons of kernel bloat by using standardised drivers, which in some cases could even be of better quality and performance than today's drivers.
One the one hand, I can understand your point of what if the interface is not the one you want? But on the other hand it's not a new problem being caused by this model. The USB webcam interface may not be the one we want, but it's the one we get. The video hardware interface might not be the one we want, but it's the one we get. The sound card hardware interface might not be the one we want, but it's the one we get. In all these instances an OS has to deal with not one, but hundreds or thousands of subtly different hardware interfaces doing the exact same thing. So adding an interface for standardised drivers really shouldn't be a big deal. Of course I'd want real experts to work together at creating good interfaces from the get go.
"Trying to get different developers to agree on a common device driver standard will be hard. Trying to get different developers to agree on a common programming language is going be even harder."
Yep, standards are always hard.
"Not just asynchronous, but 'asynchronous with IO priorities'"
Good idea. I don't want us to reinvent the wheel here, but basically we'd want to be able to expose everything the drives are capable of. I think most operating systems use a SCSI interface internally even for representing drives that aren't on a SCSI bus.
"Not just different drivers running at the same time, but the same driver being able to complete multiple requests at the same time (e.g. if there's some sort of sector cache or something) and accepting new requests while existing requests are being performed."
That's usually implied by asynchronous designs, but let's say it explicitly.