On Jeudi 28 Juin 2001 19:12, ZN wrote:
> On 6/28/01 at 11:14 AM Thierry Godefroy wrote:
>
> [long filenames support via "special" device driver and thing]
>
> >> Well, I am glad to have been proven wrong on this. Briliant idea!
> >> I wonder if a more complete spec could be made for such 'registration'
> >> mechanisms as they could be useful for other parts of the driver, not
> >> only the long file names.
> >
> >Which parts ?
>
> Exactly the ones you describe in the rest of your answer.
> 1) have a _USE and _DRIVE thing that handles the corresponding commands for
> all devices
> 2) your 'que atapi packet' thing, if slightly extended, could be used by
> anything working over IDE
> etc...
>
> Don't think that I am nagging - you have obviously thought of many things
> (maybe even everything :-) ) and I for one am VERY glad to see it, but you
> must already realize you are breaking new grounds here. I hope you will
> document it all, otherwise people will have to read the code again, and we
> know how 'well' that works :-)
Don't worry, there will be full documentation (although the doc will
most probably be available some time after the first driver release)...
> >> Regarding long file names, some kind of 'shorthand' may be required
> >> when referring to them, such as the concept of 'current directory'.
> >
> >There is already references to "current directory" into the channel
> >headers of level 2 devices...
>
> Well, that's nice to hear. Are they being used?
Yes, somewhat, but not in the way you describe below...
> >> Are we going to have the directory separateor argument again, i
> >> wonder? :-)
> >
> >Nothing to argue about: both QDOS and UNIX namming conventions may
> >be implemented into an ISO9660/Joliet device driver. They are just
> >that: "conventions"... and not driver programming constraints.
>
> I meant things like opening files at ../somewhere. i.e. embedded
> 'shorthand' for directory level up/down etc :-)
I see what you mean by "shorthand" now... Well, yes, this could be
implemented (cdr1_../myfile would then refer to the file held into
the parent directory of the DATA_USE default directory), but I don't
think it is a high priority feature, not to mention that this is not
really driver related but rather SBASIC/C library related (the PROG
and DATA_USE stuff is taken care of into the SBASIC and the C68
library procedure and functions, NOT into the directory device
drivers)...
> [Why directory drivers]
>
> >Because the IOSS takes care of most ancillary tasks when opening
> >a channel on a directory device driver:
> >
> >- device physical definition block check and allocation (if absent).
> >- channel definition block duplication in case of a shared open call
> > on an already open file.
> >- automatic freeing of channel def. block for DELETE calls.
>
> This code should have been a thing (for all I know, it is) - anything that
> needed those services would then just call it, and it could be changed or
> 'evolved' in time.
The fact is that when QDOS was written, "things" did not exist at all
and when SMSQ(/E) was written, it had to be upward QDOS-compatible...
> But what I really wanted to ask is this: is the 16 device limit only a
> limit because of the slave block mechanism using limited bits to track
> what blocks belong to which device?
I will not use slave blocks in my driver (too slow !) and this has
nothing to do with them anyway. This is a rather "stupid" limitation
in fact: the pointers to device physical definition blocks are held
(unlike all other QDOS tables) _into_ the system variables (i.e.
there is only room for 16 table entries)... I suppose that when
QDOS was written, TT considered that 16 mass storage units would
"forever" be "plenty enough"... Many other programmers/computer
conceptors made a lot of such wrong assumptions (I am sure I will
or already did make some myself in my own software)...
Overcomming this limit would involve quite nasty incompatibility
issues with old device drivers and/or software...
Note that this is somewhat balanced by the fact that you can
unlink devices dynamically under SMSQ/E and re-affect device
names to other partitions/volumes/sessions...
> >> What I emant is that 'mounting' of a devices, i.e. linking of a driver
> >> to a piece of physical hardware, should logically be handled by TRAP #2.
> >> However, there are no calls to do this
> >
> > Yes there are...
>
> Well, not for TRAP #2, which are IO management and should logically also
> manage devices, FORMAT being the case that sets the precedent. Using the
> same argiment as you have later, FORMAT is not entirely in the spirit of
> QDOS/SMSQ. It shouldn't really be a TRAP #2, but an extension (thing) like
> the _USE and _DRIVE commands.
But remember that "things" were not available when QDOS was written: FORMAT
add to be "vectored", and TRAP #2 was the closest and more logical approach
then...
> On the other hand, if there was a TRAP #2 for the _USE and _DRIVE, would
> they be in the spirit of QDOS/SMSQ?
Are there TRAP #2 for drive usage and "mounting" ? No, so there is no
point arguing about this...
> This may all sound like I am starting an argument.
Errr... yes ! ;-)
> Well, no - I am just pointing out that the QDOS/SMSQ way of managing
> devices was originally shoved into TRAP #2 in the form of a FORMAT call,
> which the proved to be insifficient.
Well, we should ask Tony then... But my guess is that FORMAT was
"accidentally" put in TRAP #2 calls. As we say in France:
"C'est l'exception qui confirme la r�gle"
(which I will risk to try to translate into: "This is the exception
which confirms the rule")
> Even using extension things to do the device management is
> insufficient for some functions - it is a problem, and eventually, it
> should be solved. I'm just tryngt to point this out.
You can do almost everything you want in "things": things are just
a handy way to vector and trace usage of routines/devices/programs/
data. The thing system is a sort of "shell" that takes care of
ancillary tasks when comes the time to (un)register or reference
the things contents.
As such, I don't see how "things" could be "insufficient" !
[meta-devices]
> Hm, but you provide some proof to the contrary in your own answer - the
> ATAPI command que. You could just as well see it as a channel, open to a
> very low-level device.
NO ! Channels are meant to exchange DATA, NOT to send COMMANDS or
PARAMETERS to a piece of hardware ! (of course, you could argue
that "commands" and "parameters" are just some form of "data",
but you won't, will you ? ;-)
> This is not even a directory device, it's just a 'wrapper' for
> the hardware. This or similar functionality is needed for
> devices in general, not just for ATAPI or what have you.
>
> Let me give you an example. Suppose someone implemented SCSI on the Q40.
> Then, you could connect an IDE and a SCSI hard disc to it. Boh would use
> the QWA file system, but here is the problem: each device would have it's
> own copy of the QWA handling code. If there was a CD connected to either
> (and here we would already be circumventing another driver that works on
> the same hardware), with a QXL.WIN on it, then the CD driver would also
> need it's own copy of the QWA handling code. And, there would be no way to
> make one be win1_ the other win2_ and the QXL.WIN on the CD be a win3_,
You are too much focused on the UNIX (more exactly POSIX) way of doing
things ! What you propose is indeed to MOUNT _different_ drives types
(SCSI, ATA IDE, ATAPI IDE) on the same "root" ("win" device in your
example). I'm sorry, but this is not the QDOS/SMS way of doing things...
You may regret (or even dislike) it, but you just can't ask for QDOS to
become UNIX !
> although they logically should be.
Don't invoke LOGIC here, as I see no logic in your proposal: they are
DIFFERENT devices (one SCSI and one IDE) on DIFFERENT hardware... Even
UNIX uses DIFFERENT device names for SCSI and IDE !
> It could be done, if they were all set to _USE another name, then some
> sort of DEV_USE would be used to make them dev1,2,3, and then a DEV_USE
> win would make them win 1,2,3. Total number of QWA copies: 3. Total
> number of directory devices used: 4. If you think about it, only one
> copy of the QWA handler code and only one device driver would really
> be needed.
This is yet ANOTHER problem that, BTW, will be addressed by my CDROM
device driver, through the use of "pluggable modules":
This problem arises from the confusion which is made between a
"device" and a "filesystem".
For a very long time, under QDOS, we had only one (custom) filesystem
for each directory device, so there was no problem associating both
the actual driver code and the filesystem management code into the
same "directory device driver" entity.
Nowadays, we face another challenge: to be able to read several
different filesystems with the same drive (and therefore using
the same SMSQ/E "device" name).
So if someone writes, say, a Joliet (or RockRidge for Richard ;-)
filesystem as a pluggable module for the CDROM device driver,
then the same module could be used with very little changes
(typically the name of the device driver thing) by another device
driver written with the same specs as the CDROM device driver...
The same thing is true, of course, for QWA filesystem.
> There are three ways to solve this problem:
> 1) IDE, SCSI, CD driver is one and the same, and therefore share the same
> name and same QWA code. Questions: handling other file systems, different
> hardware, non-fle devices connected to the same hardware, no-one else may
> be able to use QWA handling code, etc.
This is not the proper solution: devices using different protocols
(and ATA is different from ATAPI, even if ATAPI must use some parts of
the ATA protocol) should use different device drivers. Some PARTS
(mostly very low level ones) of these protocols MAY be shared though
(e.g. the ATA command queuing could be shared between ATA and ATAPI
devices).
> 2) If the drivers were written by the same author, they may have been
> internally split into smaller entities, which are then shared, and maybe
> were 'thing-ized'. This way multiplying the same code is avoided. 3 devices
> are needed still. plus a DEV_USE wrapper if we want them to have the same
> name. Other people may use the code contained in the driver(s) through
> legitimate mechanisms (things) but only if they somehow get the thing
> specs.
Drivers do not need to be written by the same author, provided proper
documentation and specs are available: this is my ambition for the CDROM
device driver.
> 3) Drivers are written to cooperate from the very start, using a defined
> and documented method for layer sharing. So, whoever has the documentation
> for the QWA thing, can link it into their driver and handle the QWA format.
> Or, they can register their low-level hardware access routines into the
> existing win driver to add the hard disks on a different interface. Etc.
No good (see above), different protocols=different device drivers
(but the filesystems may still be shared !).
> This problem is even more pronounced when devices are used that only
> transport data, for instance network cards.
> At the root of this is the lack of a well documented and controlled
> mechanism for setting up and communicating parameters to devices, as oposed
> to data, amongst other things (sic!) to link with existing functions in
> other drivers. This is a persistent problem in QDOS/SMSQ,
I _suspect_ that SMSQ/E got some clever solutions to this "persitent"
problem: alas if they actually exist (and they probably do, given the
impressive collection of things registered into a bare SMSQ/E system),
they are not documented at all... :-(
> and the reason why drivers are not written as described in solution
> 3 above - if they were, 90% of all QDOS/SMSQ driver problems would
> not exist. The idea of MDs was to provide a mechanism that would
> implement solution 3, by communicating parameters to the driver.
> I thought it would be nice to use
> an 'entity' that already exists for communication purposes to solve that
> problem - a channel. It is a well established, controlled and largely
> documented structure, not too much left to implement in ways that had a
> high probability of being incompatible across different implementations.
Be modern ! Things _now_ exists and they are also well established,
controlled and largely documented structures... Why perverting another
OS facility (data exchange) for this purpose then ?
> Wether that is in the spirit of QDOS/SMSQ, depends only on how the basic
> building blocks are modelled - in the case of MDs these were small, simple
> devices that could be linked. Their main disadvantage was that, ideally, a
> new TRAP #2 call would have to be added to manage them,
And as you very well know, there is no clean way of extending TRAP #2
under QDOS/SMS (unless the OS is loaded in memory and you POKE into
the vectors: this is the dirty way...).
> although I came up with ways to avoid this.
Through TRAP #3 I suppose... this is even worst (what about compatibility
and future TRAP #3 addons conflicting with an extended TRAP #3 set for
meta-drivers ?).
> There is absolutely no reason why you couldn't do this as a collection of
> things - given the current state of QDOS/SMSQ, there are many reasons in
> favor of that solution, the most overwhelming one being that you can't
> change SMSQ (easily) while you can implement new things, more or less any
> way you want.
And this is done cleanly !
> If you think it over well enough so that you don't need to do
> the work all over again later when a new feature is needed, then the
> problem is solved. But even in the last few messages, it is obvious that
> there are a lot of things already in SMSQ that should be well known and
> definitely documented, but are neither.
Some are (slightly, in "QDOS/SMS reference manual"), many other are not
and pertain to the "secret conspiracy" as revealed by Jonathan Hudson
a few years ago. ;-)
******************** JOCHEN PLEASE READ THIS ! *************************
More seriously, I think it's time to revamp the QDOS/SMS reference
manual with more details (even just with some header files from the
SMSQ/E sources if TT do not find time to write a proper doc)...
Jochen, any hope here ?
************************************************************************
>.../...
> >As for the CDROM device driver, this imposes to perform all the
> >transfers for a single command into the same scheduler loop call...
> >The result is that the system is "frozen" while the CDROM spins up...
> >A solution resides in the overlapped ATAPI command protocol
> >...but... it will be usable with the most recent CD-ROM drives...
> >
> >Another possibility is to ask TT to change slightly his IDE hard
> >disk device driver... in this case there would be no more conflict
>
> I would vote for the later! :-)))
I will write to Tony, but I can't tell if he will reply... he did
not to the four last FAXes I sent him (in which I was asking for
some details about the QXL to PC protocol so that I could write
a Linux module+bootstrap for the QXL).
> [Qubide]
>
> Qubide may be more problematic because it does not use an interrupt. It
> scans busy/drq in a scheduler loop,
This is exactly what both SMSQ/E win driver and my CDROM driver do (the
only problem with the win driver being that the drq state is ignored) !
So my driver will most probably work "out of the box" on Qubide !
> but I really don't remember what
> combinations it uses. There are rumours that the Qubide will become open
> source, so you might get a peek into it eventually. The addresses of teh
> varios IDE/ATAPI registers are different on Qubide but that is a
> comparatively minor problem.
No problem at all, just some "equ"s to change in the CDROM driver source...
QDOS/SMS forever !
Thierry.
