On Fri, 11 Jan 2002 15:01:34 -0500, Phoebus R. Dokos wrote: > 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:
Err... please quote at least a little bit so that I can see which among the 1E121 messages is dealt with ! > 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 Totally WRONG ! Please READ carefully what I already wrote (since June 2001 !) about this device driver: I know that my english is rather approximative, but I got no time to explain over and over again the same thing. Once for all: the CDROM device driver (and its ISO/Rockridge/Joliet/ Packet-CD extensions if someone ever implements them all) is already and will stay a LEGAL SMSQ/E directory device driver. BUT, because of the current IOSS limitations, I had to find a way to overcome the 36 (or 80 for DV3) filename length limit (no problem for ISO-9660 which also supports 36 chars max in "legal" implementations, but definitely a problem for Rockridge/Joliet extensions as well as for Packet-CD filesystem). This is done by intercepting the IOSS call for OPEN to the drivers BEFORE the directory device drivers OPEN routines are called: under QDOS/SMS, all the device drivers are called in chain (non-directory ones first) during an OPEN call until one of them reports a success into finding/opening the device/file passed as a parameter to OPEN. This can only be ensured by implementing a FAKE non-directory device driver (no limit on the device+parameters length for those...) which ONLY responsibility is to store over-36-chars-filenames in a safe place for REGISTERED directory device driver to use them later, AND to truncate the filename so that the IOSS does not report a "bad name" (because length>36) before starting to call the directory device drivers OPEN routines. > (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. There is no such problem for I/O TRAPs (TRAP #3) under QDOS/SMS: if a call can't complete immediately, an immediate return is made via the scheduler and a later try will be attempted (provided you passed a big enough (or infinite) timeout). The problem occurs with TRAP #2 calls though (OPEN/CLOSE/FORMAT/DELETE): there are some (non trivial ways) to overcome this problem, each one bringing some level of incompatibilities with existing software. BTW, in direct "sector" access mode, the CDROM device driver already implements asynchronous OPEN calls (the call returns immediately, the actual check for the presence of a CD-ROM into the device is made during the first I/O TRAP which, being a TRAP #3, is ALSO non-blocking): this already could make it incompatible with some existing software. Imagine that a software only checks for the "medium check failed" and "not found" errors after the TRAP #2 OPEN call and then only checks for "end of file" on subsequent TRAP #3 I/O calls: this is legit under QDOS (were a TRAP #3 never reports "not found"), but with the CDROM device driver "medium check failed" or "not found" will occur only after the first I/O call. If the programmer of the software in question is intelligent enough, he should have make provision to check for "unknown" errors and take appropriate measures when they occur; if he did not, then his program may well just crash ! > 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 Slave blocks are NOT a bad thing themselves: the inconsiderate usage TT did with them under SMSQ/E _IS_ the actual problem. I will use them BUT only in a few cases: when less than 2048 bytes are requested for a read, thus avoiding to re-read each time 2048 bytes of data (you can't read less on a CD) from the device each time a software reads only two bytes... For bigger transfers, slave blocks are less effective (moreover this type of big transfer is less likely to occur more than one time on the same file/blocks). Another way to use them wisely, is to limit the amount of total caching memory they can use (thus also limiting the amount of time needed to search among all existing slave blocks for your data...). IIRC Marcel uses this trick to speed things up under QPC. > .../... but the most important gain of all > would be the ability of drivers to be written in high level languages. This is not an issue as far as I am concerned (please Richard, keep cool ! ;-) > New POSIX compliant filesystems could be implemented too as well as > other things, from network to (even) USB! I don't see any reason why such "things" (they will have to be things ! ;-) could not be implemented under SMSQ/E. QDOS/SMS forever ! Thierry.
