Monty (xiphmont@mit.edu)
Mon, 30 Nov 1998 17:02:55 EST
Sorry for the delay, I was away for the Thanksgiving holiday here in
the States.
>> I realize I might be stepping into fertile flame ground here, but in looking
>> at the code for pt and ide-tape, I was wondering why the two were separate.
I should let you know you did so much more gingerly than I originally did.
>Maintaining the IDE driver is already complex enough.
>
>Gadi Oxman did some experiments to see what was involved to slide PARIDE
>under the IDE driver. The edits were not trivial.
>
>To make this work, an extra level of indirection would have to be added into
>the hardware interface. That extra indirection would take its toll on
>every access to an IDE register in every Linux system. I'd guess that
>something close to 95% of all Linux users have IDE only systems. Less
>than 1% have or use PARIDE devices.
>
>Would it make sense for everybody to pay even such a small tax to support
>a tiny fraction of users ? I don't think so.
>
>Most of the complexity in both the IDE and PARIDE subsystems is in parts
>that do not overlap.
The NetBSD people claim their indirection layer isn't more than a
small penalty (they also incorporate SCSI and ATAPI under the same
layer). Linux *is* faster than NetBSD for IDE, however... (I would
imagine that the penalty is largely at the caching level? A disk is
10,000 times slower than memory already...)
But I'm not going to rehash this part; Grant is right. Modifying the
IDE layer is probably not the most efficient expendature of energy,
and the IDE layer is certainly coded to resist change. The IDE layer
would have to be rewritten from the ground up.
I've come to think that the easiest way to meet the same aims is to
come up with a unified ATAPI/SCSI packet command interface and make
sure each subsystem implements it identically. I'm working on a draft
of a proposed interface now, along with peripheral kernel design
concerns and considerations that affect the interface. As I talk to
others, though, I'm wondering how well it will go over. I know the
CAM folks will not be pleased (but I don't like what they're doing
anyway ;-)
Trying to unite it all under a single high-level consistent interface
layer would explode as USB comes into the fold anyway.
>> But I noticed that most mt ioctl's aren't implemented for pt, but ide-tape
>> seems to be a really fully-worked-out driver for doing basically the same
>> thing over a different set of wires.
Note that what I said above applies only to direct packet command
stuff. I don't actually believe in putting alot of 'smart' ioctls
into the kernel... Why? Look at the ATAPI ioctl() for reading CDDA;
it's nearly useless with a large number of 'supported' drives as it's
error recovery is so naieve. Solaris is just as bad (The Linux
implementation seems to be a copy of the support Solaris). In
userspace, these things are easier to correct, and flavors don't
corrupt the purity of the kernel support.
>> reasons, how difficult might it be to slip paride/epat underneath ide-tape
>> (or, for that matter, paride/* underneath ide-*)? Would an interim Right
>> Thing be to hack ide-tape to write through the paride layers?
>
>You've probably missed the fact that there are actually two drivers for
>ATAPI tapes already: the ide-tape driver and the st driver coupled with
>ide-scsi emulation. If you want to do this right, start looking at
>the three drivers together. But then, don't stop, because there are
>similar issues with CD-ROMs.
Yes, yes, I'm happy to flame about CDROMs, which are about as
worse-case as you can get (the root of this problem is the wild
variance in CDROM hardware interfaces and firmware behavior).
Monty
(off topic again, and gaining speed)
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:49 EST