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/javaone _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
