On Mercredi 27 Juin 2001 05:30, Timothy Swenson wrote:
> I think the discussion about what format the CD driver should support
> is a mute point. Thierry will implement what he can/wants to implement.
> We really can only offer suggestions.
I will not have enough time to implement all I want to be implemented
into the final product before I leave, BUT I will implement at the
very least direct sector access (should be working this week or next
one), and possibly sector access into a QXL.WIN file in the root
directory of an ISO9660 CD-R.
> Personally, I'd like to see the CD driver be able to read both QWA and
> ISO9660 formated CD's.
The definitive and finished product will implement ISO9660 but NOT QWA
(note that a QWA "formatted" CD could be read using direct sector access
and qxltool though). Joliet extensions are also planned...
> It would be nice if the CD driver was written so that additional formats
> could be added in with little work. IRIX works like this. It supports
> CD's formated in ISO9660, efs, HFS, and so on. The new IRIX tape driver
> (TS) is a generic tape driver with personallity daemons. This way support
> for additional tape drives can be added without changing the kernel and
> just change the personality daemon. It would be nice if the CD driver
> could be like this.
Are you a mind reader ? This was planned from the very first specs:
I will make provision for new filesystems to be linked into the driver.
This is easy thanks to the "thing" system...
> And I am very interested in looking over the source code, be it in C or
> assembly.
It's assembly (largely commented but not yet documented)...
On Mercredi 27 Juin 2001 06:35, ZN wrote:
> Well, I hate to be a party breaker, but guess what: all standard CD file
> systems have a deeper directory structure and/or longer names than the QL
> is capable of handling with it's 36 character path+name limit.
Wrong ! ISO9660 is limited to 32 chars in filenames (path name included)
and to 8 levels of sub-directories...
> As a result,
> it is not possible to implement a directory device driver that would do
> anything but direct sector access, or some sort of bodged file access.
Wrong again !
By using a small trick, I can make a SMSQ/E (NOT QDOS !) directory device
driver to use long filenames. Here is how the trick works:
In QDOS/SMS, when an OPEN system call is issued, the IOSS (Input Output
Sub System) first extract the device/file name and asks to each non-
directory device driver if it recognizes this name as one of its device
(+parameters) name, the length of this name is not limited (well it is,
but to a bigger number of chars: 127 if the name was not quoted, 32765
if it was).
Then, if none of the non-directory device drivers reported a success,
the IOSS scans for the directory device drivers device names and if the
filename starts with one of them, sets up a new channel header for it,
copying only up to 36 chars (after the device name) into the channel
header and reporting "bad name" (QDOS) or "not found" (SMSQ/E) if this
name is over 36 chars long: thus the "36 chars limit" in current QDOS/SMS
directory device drivers...
To overcome the 36 chars limit, the only thing you need is to store
the long filename somewhere and truncate it to 36 chars so that the
IOSS does not complain; the directory device driver will then have
to retreive the stored long filename and setup proper variables for
it (e.g. a pointer) into the spare bytes of the channel definition
block.
This can be done easily through a "special" non-directory device
driver (also implemented as a thing): as a non-directory one, this
device driver will get called during each OPEN call. It will have
to check itself for a directory device name into the filename it
receives and then, if a registered device name is prefixing this
filename, to keep a copy of a pointer to the name (writing this
pointer value into the related device driver linkage block),
copying the 36 first chars of the filename into an area it owns
(typically its own device driver linkage block), and exchanging
the pointer to this truncated filename with the pointer to the
original filename (this pointer is held in A0 and should never
be changed by a non-directory device driver unless it recognizes
its own device: this is because A0 is used by all following device
drivers and IOSS open routines). The device driver then reports a
failure to recognize hhis device (in fact it got no device name
at all itself), and the device scanning continues with the
truncated filename...
When the proper directory device driver is scanned by the IOSS,
the IOSS sets up the channel header using the truncated filename
and passes the control to the device driver OPEN routine which
will find both the truncated filename into the channel header
and the pointer to the full filename into its own device linkage
block (it will then just have to copy this pointer into the
channel header adn performs the appropriate actions IOT find
the corresponding file on the medium)...
When a new device driver wants support for long filename, the
only thing it must do is to register itself to the "long filename"
thing (I did not give it a name yet) by passing it it's device
driver linkage block address (so that the device name in use
can be found at any time by the thing) and relative pointer into
this linkage block to the "pointer to long filename" (so that
the thing knows where to store the original filename pointer)...
Now why only SMSQ/E and not QDOS ? Because SMSQ/E implements
support for all TRAP #2 calls into the non-directory device
drivers. E.g., when issuing a DELETE system call under QDOS,
only the directory device drivers list is scanned for the name
of the file to delete, while under SMSQ/E, the non-directory
device drivers (e.g named pipe driver) which registered
themselves as supporting DELETE as well (this is done via a
magic word and flags) will get called BEFORE the directory
device drivers... QDOS would therefore NOT support DELETE with
long filenames, while SMSQ/E will...
> I won't even go into ideas of having the CD driver being modular,
> something that links to a regular 'ide' driver through dorect
> sector access - cause QDOS has no real linking capability,
> so it would have to be yet another bodge.
Still wrong...
My CD-ROM device driver is implemented as a thing and will
implement a registering "thing extension" that will allow
for a "module" to plug itself into the device driver. The
module will have to implement OPEN, CLOSE and all I/O
sytem calls for its own filesystem. When an OPEN call will
be issued to a CD-ROM device, the CD-ROM device driver will
check for any plugged filesystem and pass each registered
filesystems OPEN routine the filename: either this filename
comply and is held on a CD-R format that the "module"
recognized and the module will return without error code
(in which case, the CD-ROM driver will abort the scanning
sequence and "mark" the channel as owning to the successful
module), or it returns with an error code (and the scanning
continues, the own OPEN routine of the CD-ROM device driver
being executed in last ressort).
The "module" will be able to use the low level routines of
the CD-ROM device driver (as will any SMSQ/E program: the
routine are, here again, implemented as "extension things")
and will have to use the CD-ROM device driver linkage block.
Zeljko, just a small advice: when you don't see how to
implement something under QDOS/SMS, just think "thing" ! ;-)
> Let's also remember that users that do not have a Q40/60
> may also want CD access.
Provided I know where to find the ATA registers, I could
port the CD-ROM device driver on any hardware based system
(don't even think about porting it on emulators !). Qubide
is a candidate provided some doc (or source) is available
for it...
QDOS/SMS forever !
Thierry.
