On Vendredi 29 Juin 2001 07:14, ZN wrote:
> 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.
I have nothing against arguments (in the "debate" acceptation of the term,
not in the "dispute" one of course)... actually, as many french people, I
like to argue about anything ! ;-)
> Thierry, I am not arguing 'my' approach over yours. We are really on the
> same side here and arguing serves no purpose.
Quite the opposite (we can now have an argument about arguments: how
lovely !)... I thing that this helps to make things (no pun inteneded !)
clearer in both "parties" mind and sometimes encourage some sort of very
benefic brainstorming.
I find it quite stimulating !
> 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.
You are a QDOS/SMS user and, moreover, a remarkable hardware designer:
as the later, I have myself no ground at all, and your experience may be
quite profitable to me, especially in the device driver scope...
Don't under estimate yourself nor over estimate me !
> 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 :-)
I always do so... ask to those who made suggestions for the software I
wrote in the past.
> .../... (lots of things cut, all of them agreed to)
>
> [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'.
This is only because of lack of documentation about the latest things
implemented in SMSQ/E (such as the DV3 thing), but they do setup a
standard by themselves: the problem bieng that to date this standard
is "secret" !
> For better or worse, you will be the one that will define the standard,
> and it's a big responsibility, and a big job.
Not so big a job, but yes, this is an important responsibility: just
imagine that I setup a new (well documented) standard that would be
incompatible with an already (but undocumented) standard setup by TT
himself... what a waste of time and efficency !
> .../... (snipped and mostly agreed)
>
> >> [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.
This is a rather RARE usage though...
> 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.
OK, here you got me ! I did not think about USB (note that I got a little
time to think about it as there is currently no QL hardware fitted with
USB ;-).
But you could have invoked bidirectional parallele port as well: you may
attach SCSI, IDE or whatever "converter cable" you want to it !
So how I would implement, say, a SCSI driver over a bi-directionnal
(SPP, ECP or EPP) parallele port ?
I think that I would use some sort of encapsulation. The lower level
stuff (exchanging data over the port itself) being processed by a
vectored (with things) low level protocol pertaining to the parallele
port driver, and the SCSI level, by all but the lowest level of the
(hypothetic) SCSI driver, the lowest SCSI level being replaced by
the encapsulation protocol...
> 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?
No, they just use a different medium, and that's enough for having to
distinguish them. Anyway, the user do and have to know if the file he
wants to get access to is held on the hard disk, on a CD-R or on a ZIP
cartridge. So there is no real harm (on the user point of vue) to give
them different device names.
The question is more picky for two "identic" (in their functionnalities)
devices using different protocols (such as two hard disks: a SCSI one
and an IDE one): on the user point of view they are just hard disks,
and despite of this fact, they are called differently (not only in
QDOS/SMS, but in UNIX too, the difference in UNIX being that both
disks may be mounted on the same filesystem and their contents then
just appears in different directories)...
This is why I already thought in the past to re-use Hans Peter
Recktenwald's QVFS (excellent !) idea and re-implement it in a clean
way (the problem with QVFS was precisely the use of "extended" and
therefore non-standard TRAPs so to make for the limitations in QDOS:
with SMSQ/E there is no such limitations and the need for specific and
non-standard system calls vanishes).
Here again, the problem is TIME. It is _not_ difficult to implement a
SMSQ/E QVFS meta-filesystem (that is a filesystem making all other
filesystems available through the same naming convention). I even
already found some ways to implement "soft links" and many things
that are lacking under QDOS/SMS... but I will probably only get enough
time for doing this after I am retired !!!
> .../... (about 1 Gb of interesting stuff stripped: time, time... ;-)
> [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.
> .../...
No, the queue code (at the time being it's a group of extensions into
the "CDROM" thing, but I will make it an independant "ATAPI" thing
later) only takes care for:
- being given a drive number, checking ATAPI protocol support and
reporting drive type to the device driver (or an error if the drive
is ATA only or absent). (vectored as an extension thing)
- registering (queueing) packets that device drivers want to send to any
ATAPI device (on any controller). (vectored as an extension thing)
- send these packets to the proper device on the proper controller (at
the time being there is only one queue for all controllers, I will
later implement one queue for EACH controller, this way more packets
will be exchanged each seconds and a "blocking" controller will not
block the others).
- exchange the data (if any) resulting from the execution of each packet
command, buffering it where the device driver asked to.
- unqueuing packets (either once the data exchange is completed or on
demand from the device driver). (vectored as an extension thing)
- reporting any error to the driver and flaging the various steps
completed (packet command sent, data exchange completed).
BUT the driver still must fill-in the packet data (command+parameters)
itself, as well as reserve any needed buffer and set the packet header
(holding destination drive number, data buffer address and size, and
various flags).
So the device driver still needs to know what ATAPI command is to be
sent for a given action (e.g. reading a sector) to be performed. The
advantage for the device driver is that it has nothing to know about
the ATA protocol, nor about the IDE registers address/arrangement,
nor about possible conflicts with other ATA devices...
>.../... (most of this stuff has been replied above, the rest is
> seconded).
>
> OK, now, Thierry, now don't flame my pants off ;-))
I don't think your pants are in a so bad state after this reply,
are they ? :-))
QDOS/SMS forever !
Thierry.
