On 6/28/01 at 11:14 AM Thierry Godefroy wrote:
[lots snipped]
OK, this is supposed to be a discussion, not an argument, so let me make
some things clear right here.
Thierry, I am not arguing 'my' approach over yours. We are really on the
same side here and arguing serves no purpose. If nothing else, I've written
no QL software, and you are famous for it, so you have done infinitely more
than I have, therefore I really have no grounds for arguing at all.
Besides, YOU are doing the driver, so you will eventually do exactly what
you want. I'm just hoping you are keeping an open ear :-)
You did pull my tongue about MDs and I just told you why I envisioned them
the way I did, that's all. I agree with all of the ideas you expressed,
though not with all details. I'll elaborate later.
That said, on to the matter at hand:
[Documentation]
I am relieved to see you are going to extensively document your effort.
There are surely people who will use and apreciate the documentation.
[Directory shorthand and directory separators]
Agreed, it should not be handled by drivers anyway. On that level, one
works with channel IDs, not file names.
[hidden things]
>> [device driver speciffics] should have been a thing (for all I know,
they
>> are) - 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...
Agreed, except the part about SMSQ/E. QDOS has no way of knowing if drivers
are internally made up of several things that pass stuff to each other, so
no real compatibility issues there. The only reason I mention this, and you
later allude to, that this is how some SMSQ/E drivers may actually alredy
be constructed, it's just that it isn't documented, or at least the docs
are not widely available.
[16 device drivers limit]
> 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)...
So basically, the only way to circumvent this would be to modify SMSQ/E.
OK, no-one is holding their breath here :-)
[Trap #2 and FORMAT]
> But remember that "things" were not available when QDOS was written:
FORMAT
> had to be "vectored", and TRAP #2 was the closest and more logical
approach
> then...
Oh, I agree. What is 'right' here is a philosophical question. When
implementing a new driver the available resources should be used to the
greatest advantage. As I said, you did 'pull my tongue' and I explained why
and how the MD idea came about. The reson why channels were used was
because they were there, and it minimized the amount of new stuff to
invent. It wasn't implied that's the ideal or only way.
I will, however, stand by my conviction that, as they are currently
documented, QDOS/SMSQ drivers and devices leave a lot to be desired. It is
high time some of that was addressed, and I for one admire your courage for
doing so.
However, since you will, in essence, be setting up the standard, I think we
both know it's for your own good to leave 'space for expansion' and that
just involves some advance thinking - and I'm sure you are doing that.
> 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"
Oh, I completely agree there. The saying translates directly and completely
accurately into Croatian :-) FORMAT was just put into TRAP #2 because, even
though it may not have been the ideal fit, it was the best available at the
time.
>> 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 trying to point this out.
> You can do almost everything you want in "things"...
> As such, I don't see how "things" could be "insufficient"!
Not things themselves. The nice thing about things is that they can be
anything ;-)
I was referring to the available extensions to date. Your own admission
about guesswork about the _DRIVE extension makes me think it would be a
good idea to decide on some sort of a set of standard extensions. Or at
least document the existing ones, and proclaim them as standard :-)))
You yourself are introducing new ones here - long file name handler,
command queue.
While no-one can predict the future, we can make very educated guesses. I
was just making mental leaps, really. I do agree that POSIX is not the
be-all and end-all, but it is a good model to look at, and while it
certainly should not (or even cannot) be copied verbatim into QDOS/SMSQ,
there is no harm in 'stealing the good bits' from it.
[meta-devices]
> 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 ? ;-)
I could but I won't :-) You are right, but you cannot deny that there is a
need to pass control information to drivers and even hardware (this being a
case of the 'simplest possible' driver) in a clean manner - and more
importantly, in a 'standard' manner. Things as such provide the 'clean'
part to that, but of themselves they do nothing for 'standard'. For better
or worse, you will be the one that will define the standard, and it's a big
responsibility, and a big job.
> 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...
I don't want to see QDOS become UNIX - even if it could. QDOS, however, has
potential to be extremely device independant, and do that in a very clean
way. The example I gave was intended jto demonstrate what could be done,
and in fact, it would be just one of the effects of total driver layer
sharing - it does not mean that that particular example must be
implemented, or that it's the 'right way'.
The most important part of the above example is that drivers can end up
reusing parts of other drivers that already exist, without programmers
having to have the sources to them to know how to code their own, cause
there has to be a simpler way. Depending on how this 'binding' of the parts
is handled, you may (note: MAY) end up with an ability similar to UNIX
mounting.
>> [devices of the same kind accessed through different hardware being
treated as different devices] although they logically should be [treated
the same]
> 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 !
This opens a HUGE can of worms. Later on you mention the integration of
file system and device. It really goes deeper than that - you should add
'hardware attachment' to the list.
Things were easy when the only thing you could connect to a floppy
interface was a floppy. Trouble started when they inroduced tape drives.
With IDE things got complex faster - it started off as hard drive only, now
you can put almost any storage device (including floppy) onto it, using two
distinct protocols. With SCSI, things are even worse, cause there you can
use non-storage devices. Then, we have non-storage oriented interfaces that
got storage devices grafted to them, such as parallel ports. We don't have
USB yet - and if we did, we'd be in DEEP trouble, more or less anything can
be on USB.
For the sake of (a really irrelevant) argument, let's assume the question
here is, how do we treat QDOS/SMSQ devices - by the device ultimately
attached, by the protocol(s) it uses, or by the hardware interface it first
came bundled with? You can find examples of all of that in existing
drivers.
Let me give you an example:
On Qubide, you can use a ZIP drive or a LS120, and address them as win even
though they use the ATAPI protocol, while 'real' disk drives use ATA. CD
would use ATAPI too, but would be called CDR, would this be because it uses
a different file system? OK, then how about a QXL.WIN on a CD. Would this
be CDR or WIN? What if someone implemented SCSI - and put a CD on it? Would
this CD now be called SCS? And if it was a hard drive? We already have them
on ATARI and they are WIN - and they use the same protocol as the SCSI CD.
How about a SCSI scanner or printer? Or, what of we put a regular floppy
into a LS 120 - it would use ATAPI to get to the data, and the floppy
format on the disc. It's name? WIN, CDR or FLP??? BTW why does the later
not work (rethorical question :-) ). In other words, it's a mess.
One could use the argument that hardware interfaces and protocols do
absolutely nothing on their own and that without the 'end' device they are
at best 'virtual', they are there to implement a protocol or protocols of
some kind. So, one could argue that devices should ultimately be referred
to by what they really are.
But you know what? Weather hard discs on IDE and SCSI are called the same
or not, or in fact, how a device is called is ultimately a moot point - and
in fact, even on the level of a driver (I'll get to that later). The user
can probably get used to any name, but not to endless explanations why it
is so difficult to read QWA on Qubide, why we can't read a floppy in a
LS120, etc, when logically (and it IS logical!) it should not be a problem.
Maybe the solution to the above sounds a bit like POSIX? As far as I am
concerned, I'll be eternaly happy and grateful if Thierry invents a model
of handling devices, call it Thierryx, that finally puts a stop to this
problem - or at least moves in that direction. And again, as far as I can
see, that's what Tierry is doing. The reason why I am so vehement in
pointing this out, is because the same kind of problem happens within
nearly all QDOS/SMSQ drivers, it's just not equally visible - and there is
now someone willing to tackle at least part of it. So Thierry, I am not
telling you NOT to do it, I'm begging you to do MORE or at least plan for
it ;-)))
[handling different file systems]
> This is yet ANOTHER problem that, BTW, will be addressed by my CDROM
> device driver, through the use of "pluggable modules":
I really admire your courage to do what you are doing, I just wonder if you
know how big a can of worms you have opened (and that's actually a GOOD
thing, it desperately needs to be opened).
I certainly do not expect your CD driver to solve everything - it just
can't do that. But here is an example of what it might do, at no big cost
to you. In fact, I'm almost sure it's already being done.
Let's take your ATAPI command queue and the ISO file handler as examples.
If TT wrote his IDE driver with a way to access the ATA/ATAPI queue, like
you have done with the command queue, you would never need to know anything
about the actual IDE hardware at all. I presume your own driver uses the
queue. If so, when someone comes and puts SCSI on Q40, assuming your driver
can bind to other queues, not just it's own ATAPI queue, whoever takes the
task of writing the SCSI driver, need only write up to the point where he
implements a compatible queue. Your driver then links to it and voila, we
have SCSI CD ROM access. On the other hand, whoever does SCSI, may decide
just to use the ISO file system handler. But this SCSI 'driver' would
hardly be a driver in the SMSQ sense at all - it would be just a thing
which linked to other things, possibly from other drivers, forms a complete
driver. Similairly, if you knew there was a QWA access thing in SMSQ, you
would be crazy to write one of your own - you'd just use the one already
provided. It may not be posix, but the spirit is there :-)))
Basically, what is needed is an ability for parts of your driver
(implemented as things) to be linked into other drivers, and your driver to
link in parts of other drivers. Things provide this functionality. How much
you wish to dictate what things a driver needs to have is where you will be
setting the standard. Ideally, there should be at the very least a template
on how the things are linked, and somewhere in the far future, some kind of
a utility to do so.
>> 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...
> This is not the proper solution: devices using different protocols
> (and ATA is different from ATAPI...) should use different device
> drivers. Some PARTS (mostly very low level ones) of these protocols
> MAY be shared though
If things were as you describe above, using a hard drive and a ZIP drive
(one is ATA the other ATAPI) would need separate drivers, even though they
may both contain a QWA file system, and are extremely alike in form and
function. Or, if a CD with a QXL.WIN was inserted into the CD ROM, the
QXL.WIN couldn't possibly be called win something. Before you jump to
conclusions, what I am NOT saying that the same driver should be used. The
soulution above IS wrong, and clumsy, but it has been used - case in point
being Qubide, with ZIP/LS120 support. What I AM saying is that there are
considerable advantages if any distinct function (layer?), not just the
lowest level of the two (or more) drivers, can be shared. For instance, if
a win device driver was written like your CD driver is, win could have ISO
plugged in (to make a CD appear as a hard drive), just as cdr could have
the QWA plugged in (to read a QXL.WIN file).
Bottom line: not only does the CDR driver need the ability to have a 'hook'
to connect to other file system handlers, but the one that it implements
natively (ISO in this case) should be 'hookable' from the outside.
>> 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.
> 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.
Great! I wish it was TTs ambition as well, I'm sure you know that's who
I've been alluding to in the example above.
>> 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 !).
Notice, I said: OR. I don't see what's so bad about it, but I have
discussed this in depth above. Different protocol = different driver has
a fair amount of 'because I said so' to it, but at least it would be
consistent. There are instances where the hardware attachment or the
ultimately referred to device may be a better choice, but that's really
irrelevant. My point is that a well though out thing sharing and linking
scheme supports either (or all) approaches.
>> 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:
So do I.
> 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... :-(
You hit the nail on the head right there.
>> The idea of MDs was to provide a mechanism that would implement
>> ...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.
> 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 ?
No objections on doing anything that solves the problem. As I said, MDs
were an IDEA.
> 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...).
EXTREMELY dirty. But, most of the 'traditional' _USE and _DRIVE
implementations (NOT the ones in SMSQ) are only marginally less dirty, so
is defining a new boot device to enforce a certain order search for boot
code.
>> although I came up with ways to avoid this.
> Through TRAP #3 I suppose... this is even worse
No, it was actually through TRAP #2, FORMAT (precedent being things like
FORMAT ram1_mdv1_) to set up parameters normally handled by WIN_DRIVE, the
advantage being it could also set up other things, or alternately through
OPEN (by opening device number 0, you can read device parameters or write
new ones).
[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) !
Yes, I picked that up from Richard's post. I was referring to Qubide code V
<2.0. Newer code has limited ATAPI support to handle ZIP and LS120. I am
not sure what consequences that will have.
OK, now, Thierry, now don't flame my pants off ;-))
Nasta
