[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Device Driver Framework (attached thesis proposal)

From: Tom Bachmann
Subject: Re: Device Driver Framework (attached thesis proposal)
Date: Tue, 24 Jan 2006 14:02:21 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051031)

William Grim wrote:
Tom and Mike,
I have been thinking about these problems, and I'm currently at the conclusion that for the definition of a device driver framework, having bus drivers is not necessary or even wanted. However, I will likely produce an IDE bus driver based on deva's IDE driver for use with my hard drive during the testing phases of my implementation. I will probably also produce a PCI bus driver for use with the NIC in my PC. I do not plan to incorporate bus drivers into the framework, however, since a bus driver is something that can be done by applying the framework I will provide (which in the future may include an IDL). Things like an IDL, architecture, design, and organization are what make a framework.

AFAIUI you plan to just provide the framework, _no_ drivers?

As for session free protocols, could you elaborate?

This is just an intuiton, but session based protocols usually need more complex management mechanisms both on server and client side. For e.g. a disk driver that is taken over by a filesystem server you could argument that there are usually long running sessions so the overhead would be small. In fact, I cannot yet think of a driver that can be used in a session free way (maybye a sound card driver?).

I agree that indirect talks to drivers should be avoided. In fact, when clients request (and get) a device driver, they get a device interface page that can be used to speak directly to the device. However, if a device is externally scheduled, some communication with the DDM may take place to make sure an operation does not interleave with another operation when it shouldn't (such as printers, card readers, etc). I may need to clarify this and will review my draft again soon to make sure it's stated correctly and doesn't introduce potential DoS. Return IPCs from the drivers will follow an at-most-once policy when replying. I'll add this to the draft proposal. Thanks for mentioning it, because I don't think I explicitly thought about it. Again, I really appreciate your efforts in browsing my proposal. I do plan to make it useful to the project. Talk soon!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]