On 6/29/01 at 7:59 PM Thierry Godefroy wrote:
On 6/28/01 at 11:14 AM Thierry Godefroy wrote:
[lots snipped]
>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 ! ;-)
I noticed :-) I thought I wasn't too bad either :-)))
>>> Channels are meant to exchange DATA, NOT... COMMANDS or PARAMETERS
>>> (of course, you could argue that "commands" and "parameters" are
>>> just some form of "data"...)
>> 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... in a clean manner - and more importantly, in a
>> 'standard' manner. Things as such provide the 'clean'... but of
>> themselves they do nothing for 'standard'.
> This is only because of lack of documentation about the latest things
> implemented in SMSQ/E... they do setup a standard by themselves...
> 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 !
True - _IF_ TT finally comes out and documents it. As long as it's not
documented, it's only useful to people who have the source, and have the
will, and TIME to read it and understand it. I.e. useless for 99% of all
users.
So, the question is, what if TT never documents it? As the saying goes,
left to thems selves, things tend to go from bad to worse.
>>> they are DIFFERENT devices (one SCSI and one IDE) on DIFFERENT
hardware...
>> 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.
>> ...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 parallel port as well: you may
> attach SCSI, IDE or whatever "converter cable" you want to it!
I actually did, just not in detail, and I am glad you see my point.
>So how I would implement, say, a SCSI driver over a bi-directionnal
>(SPP, ECP or EPP) parallel 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...
In other words, if all drivers were implemented as things with 'externally
visible' vectors into the code that handles the various 'layers' in their
protocol, given a set of drivers, that may not be directly related to your
device, but as a collection have all the necessary building blocks your
device would need, writing a driver would be almost trivial. It would
involve reading the docs for the drivers to see how the things in them are
used, and writing code to connect them in a way you need. End of story, we
have a driver. In fact, if one day someone decided to do a standard layer
'binding' thing, anyone could connect the required pieces, just as easily
as typing WIN_DRIVE something. I like Thierryx already :-)))
See, this is what really upsets me - that there IS a possibility to make
writing drivers go from almost impossible to almost trivial, and it's not
being used!!! So please understand me when I get a bit persistent with my
arguments :-)
>> ...the question here is, how do we treat QDOS/SMSQ devices - by the
>> device... attached, by the protocol(s) it uses, or by the hardware
>> interface... You can find examples of all of that in existing drivers.
> 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...
(Kneeling on the floor) Oh, merciful God in heaven, I am getting through! I
am finally getting through! Oh, thank you, thank you, thank you!!! :-)))))
> 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...
> Here again, the problem is TIME. It is _not_ difficult to implement a
> SMSQ/E QVFS meta-filesystem...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!!!
I know THAT feeling. But as long as you have an idea of doing this, it will
be in your thoughts when you design and code what you have time for. So, if
you ever get extra time :-) you can come back to it - and even better, if
you document it, someone else can do the work.
[interesting ATAPI queue specs snipped]
> 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...
This is understandable, since other drivers that may be using commands that
are not used by a CD read device will 'link' here. There is nothing
preventing another 'layer' to be added on top of the ATAPI queue that
provides, say, access on a sector level via a couple of standard functions
(get/put etc), so when the user uses THAT layer, he does not have to know
about ATAPI commands.
When drivers are written this way, you only need a couple and you already
have all the building blocks for a huge variety of devices, and that's
where the simplification comes from - no need to code things that are
already coded.
>> 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 ? :-))
Not more han ususal, no :-))
Well, now I'll stop wasting your time and let you go back to coding the CD
driver :-)))
Nasta
