Re: Device Driver Framework (attached thesis proposal)

[William Grim]

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.

 

As for session free protocols, could you elaborate?

 

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!

--
William M. Grim
Computer Science Master's Student, Southern Illinois University at Edwardsville
Unix Network Administrator, SIUE, CS. Dept.