On Tue, 08 Jan 2002 10:36:08 -0500, Phoebus R. Dokos wrote: > Just my two cents.... > (and pardon my cluelesness in many parts) > > Just got the QDOS/SMS reference manual and begun (thanks partly to the work > of Norman with assembler and the good contributions of every savant one in > the list) to understand roughly a little more on how SMS works. Based to > all Thierry did with the ATAPI drivers
The ATAPI thing is only responsible for the ATA/ATAPI protocol layer, it does not implement anything directly related with filesystems; it is only responsible for sending and receiving ATAPI packets (as well as a few ATA commands) to the ATAPI-compatible devices on the ATA-IDE interface (either the ISA I/O board of the Q40/Q60 or the Qubide board of SGC-based systems). BTW you may use it from either assembler, SBASIC or even C (I will also write a small C library for it)... OTOH, the CDROM thing (which is still in embryonic state for now) is responsible for the standard SMSQ/E filesystem API implementation (the TRAPs #2 and #3), provides support for reading data from a CD-R (on a direct access basis), and _will_ provide full facility to plug filesystem support modules in it (ISO-9660 and its extensions, namely Joliet and Rockridge, as well as packet-CD filesystem): I will probably write the ISO-9660 pluggin myself as well (and then perhaps another programmer will follow my steps and implement other extensions/filesystems pluggins)... > wouldnt it be possible to go a > similar way (and by reusing as much of Thierry's code - no use of > reinventing the wheel!) and provide an interface for ALL devices under SMS? > > The way I think about it if a Device Driver API (along the lines of the > Meta devices proposed by Nasta) was implemented as a thing it would be > possible to trap all IOSS functions and translate them to something a > device would understand and vice versa. What could be done under SMSQ/E is something similar to QVFS (which was written by Hans Peter Recktenwald) but that would use all the standard SMSQ/E TRAPs (QVFS did not, by design and because it was to run on QDOS as well: the DELETE system call could therefore not be implemented and had to be supported by a special TRAP #3 call). Using things and a more memory based approach (for example QVFS was using a file to define the "mount points": IMO this should be held in memory and "(un)mounts" should occur via an extension thing call), this could give you support for UNIX naming conventions on all filesystems (including old ones), with long filenames support (as well as soft links) while preserving the backward compatibility with software using the QDOS file naming convetions (i.e. it would still be possible to access the QDOS filesystems directly). Note that there is no need to change the API (TRAPs) to obtain this dual compatibility... This is one of the projects I have but I never found the time to implement... Note that I did _think_ a lot about it though and got most of the solutions to the problems such a thing/device driver raises. See also the old discussion we had in this list with Richard about non- blocking TRAP #2 calls... > This API (?) Thing could be linked as a module to SMSQ/E No need for this, it could just be loaded at boot time as any thing/device driver. Its actual (de)activation could be made via an extension thing call (i.e. a standard extension thing call in assembler, a new keyword in SBASIC, a new library function in C, etc...). > together with a UN*X-like filesystem driver written for it In fact it would INCLUDE the UNIX to QDOS file naming translation... no need for a new UNIX filesystem. > and provide at the same time the much needed fs update and a method of > adding devices logically (I find that the UN*X like approach of devices > being part of the filesystem extremely useful). Yes, see the "mount" discussion above... Note that even newer device drivers/filesystem (such as the future CDROM/ISO9660 one) which already understand the UNIX naming convention could still be "mounted" (with a "do not translate" flag)... > Additionally it could standarise device driver creation by setting > a uniform all-encompassing standard for device driver writing. This is another story !!!... and another thing (in fact a vector collection to be glued into an extension thing) to write ! QDOS/SMS forever ! Thierry.
