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 :-)
>> 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?
>> 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 do see one remaining problem, though. There is still a limit to the
>> number of directory devices that can be in use simultaneously.
>Yes, 16...
This is why your thing approach is perhaps the best given circumstances. If
that is in the philosophy of QDOS/SMSQ is, well, a philosophical question,
but I'll get to that later.
[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.
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?
>And also because non-directory device drivers don't get listed into
>the programs that scan the directory device driver linked list to
>find out which directory devices are available on the system (QPAC2
>Files menu, Cueshell, PWfile, etc)...
I see what you mean - this cannot be solved by a driver :-(
>> 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. On the other hand, if there was a TRAP #2 for
the _USE and _DRIVE, would they be in the spirit of QDOS/SMSQ?
This may all sound like I am starting an argument. 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. 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.
> Under SMSQ/E this is handled through extensions things when needed
> (i.e. floppy and ramdisks do not need this mechanism, but hard disks
> and ATAPI device do and got one). For hard disks... you got the
> SBASIC WIN_DRIVE command (which in fact calls an extension from the
> "WIN control" thing)... With the CDROM device driver, you got CDR_DRIVE
> The problem is that I don't have the "WIN control" specs, so I don't
> know if my implementation of the "DRIV" extension [is correct][
>> but special parameters passed to open/close or even format calls could
>> be used for this.
>I see the "meta device" sea serpent emerging once again here... ;-)
>Let me say that this is (although definitely possible) NOT in the
>philosophy of QDOS/SMS. TRAP #2/TRAP #3 are related to channels
>(with the notable exception of the FORMAT TRAP #2), and NOT to
>anything related to device driver (or drive) parameter settings...
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. 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_,
although they logically should be. 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.
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.
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.
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.
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, 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.
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, although I came up
with ways to avoid this.
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. 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. The disadvantage of this approach
being, someone has to come up and blaze the trail - and then map it, i.e.
provide documentation. I have full confidence that Thierry will do a great
job!
>> IDE is the example that comes to mind on a QL. Suppose that the user
>> connects a hard drive and a CD ROM as master and slave on a single IDE
>> channel.
>This is my case on my Q60... But IDE specs do take care for this
As you have mentioned below, IDE specs are not the problem - this sort of
setup is covered by them.
>> Unfortunately, most (if not all) drivers assume the hardware will
>> exclusively be used by themselves - and here we have a problem,
>> they rely on the state of registers to be preserved.
>You are alas right on this point: the built-in SMSQ/E hard disk
>device driver thinks it is the only one to own the IDE controller
>and therefore makes some risky assumptions (and simplifications)
This is exactly what I meant. IDE just stands out in this case. Arguably,
if each device was a master, the problem would not exist. However, I am
glad to see that Thiery has decided to do it right :-), since solving of
this problem also paves the way for other devices.
>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! :-)))
[Qubide]
Qubide may be more problematic because it does not use an interrupt. It
scans busy/drq in a scheduler loop, 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.
>Hardware is not the problem here: software (drivers) is !
Well, you won't find me contradicting there!
Nasta
