I'm working on the VFS layer of SharpOS and have been talking a bit and want to work some more with Phil on the driver interfaces. I'm all for the death of I/O-Control calls. We're trying to get drivers to have strongly typed interfaces and I'm going to push to go a bit in the direction WDM has gone with its layered approach.
We're not that far away. I'm not really convinced that we need a driver class library though. Hardware is very different sometimes, that I tend to believe this only creates bloat. I am more inclined to give driver devs a framework of code for specific purposes, they can reuse. E.g. schedule a DMA transfer and wake, when the DMA is done or alike. I think we're on a good way here. grover -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jonathan Dickinson Gesendet: Freitag, 11. April 2008 10:11 An: [EMAIL PROTECTED]; sharpos-developers@lists.sourceforge.net; [EMAIL PROTECTED] Betreff: [SharpOS Developers] Driver Architecture Hi All, I came across a rivetting article on how Windows (as it stands) is ultimately doomed. <http://www.codeproject.com/News.aspx?nwid=6364> While this is, possibly, good news for us (and Linux) the author raised a rather interesting architecture. Given that the following architecture is the norm (I think): Hardware -> Floppy Driver -> Floppy Disk 'Unifier' -> Disk Driver -> FS -> Shell How about something like as follows: Hardware -> Toshiba Floppy 'Unifier' -> Floppy Disk 'Unifier' -> Disk Driver -> FS -> Shell Essentially at each layer you have VERY well defined interfaces that the next layer expects. E.g. Toshiba Floppy Unifier: * Timing management * Hardware I/O * etc. <- Read(long track, long bla...) -> DataRead(byte[] data, long track, long bla...) Floppy Disk Unifier: <- Read(long offset, long bytes) -> DataRead(byte[] data, long offset, long bytes, long bytesRead) Device Manager: <-> string[] EnumerateDevices(); Disk Driver: <- Read(long offset, long bytes) -> DataRead(byte[] data, long offset, long bytes, long bytesRead) Thus we have one more layer where all the common function for floppies are translated into one universal floppy device interface, which our drive layer interacts with. We would eventually land up with something like the following (>- means communicates with, *not* inherits): <begin example> Top Level: InputDevice : Device DriveDevice : Device DisplayDevice : Device SoundDevice : Device Second Level: KeyboardDevice -> InputDevice MouseDevice -> InputDevice RichInputDevice -> InputDevice FloppyDevice -> DriveDevice IDEDevice -> DriveDevice ATADevice -> DriveDevice SATADevice -> DriveDevice SCSIDevice -> DriveDevice VGADevice -> DisplayDevice MixerDevice -> SoundDevice ThirdLevel: PS2KeyboardDevice -> KeyboardDevice PS2MouseDevice -> MouseDevice SomeWacomDevice -> RichInputDevice SomeMultitouchDevice -> RichInputDevice ToshiaFloppyDevice -> FloppyDevice NVidiaSATADevice -> SATADevice BiosVGADevice -> VGADevice GeforceVGADevice -> VGADevice SoundBlaster16Device -> MixerDevice FourthLevel (optional, some hardware manufacturers may find this useful): Geforce6600Device -> GeforceVGADevice Geforce7200Device -> GeforceVGADevice <end example> Such abstractions would ensure the least time spend creating new drivers. Management etc. could be completely managed by the above layer (e.g. CQ <command queueing> on the DriveDevice), without these abstractions being included in each device. The DriveDevice could even intelligently manage requests so that certain busses don't get flooded. The advantage of working this way is that NVidia can completely replace the DriveDevice optimized for NVidia mobo chipset X. Any ideas? -- Jonathan ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao ne _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
