At 06:45 рм 11/1/2002 +0100, you wrote: >On Fri, 11 Jan 2002 00:04:59 +0100, Richard Zidlicky wrote: > > > On Thu, Jan 10, 2002 at 10:00:33PM +0100, Thierry Godefroy wrote: > > > > >
No criticism whatsoever however just to satisfy my curiosity and with my limited knowledge, isn't the method you proposing actually a drawback? If (and if I understand Richard correctly) you take away all i/o functions from QDOS/SMS by implementing a thing that would report itself as a non-directory device which will manage ALL devices directory and non - directory (in the beginning File I/O and later on maybe video or sound) and by implementing a SCSI disconnection type of operation (that is creating a software representation of disconnect feature: send the command to the device to do whatever and report back when it's finished) wouldn't that be A LOT faster and open up a whole new world of possibilities for QDOS/SMS? This way we wouldn't lose the (let's call original QDOS/SMS i/o) legacy support and at the same time you could implement a whole multitude of device drivers. Also you wouldn't have to remove or disable the IOSSS module (possible according to TT) and at the same time effectively kill the slave blocking mechanism... no block devices no slave blocks ;-) hehe (Yeah I know it's like going from Paris to Calais via Moscow.... nonetheless effective and non intrusive). All i/o mechanisms will be protected, older apps will have what they want and newer apps will have more :-). A kind of fancy memory protection scheme should be devised but the most important gain of all would be the ability of drivers to be written in high level languages. New POSIX compliant filesystems could be implemented too as well as other things, from network to (even) USB! Phoebus Maybe I am wrong of course but then again you will show me the light (as always :-)))
