grant@torque.net
Mon, 23 Nov 1998 14:00:47 -0500 (EST)
> 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.
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.
> 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.
But it also does an awful lot of other things that just don't matter in
the low-bandwidth world of parallel port devices.
> 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.
> Anyway, this seems so obvious I'm sure that there are lots of good reasons
> for not doing it, so before I spent any copious-free-time getting into
> paride driver hacking I thought I'd ask.
There was a volunteer a few months ago who intended to fill in the missing
mtops, but we haven't seen a result yet. If you want to take a stab (along
the lines of what you've already done) and send me some patches, I'll be
happy to incorporate them.
> In other news, for what it's worth... I added the two lines to pt to make it
> handle the MT_WEOF (write filemark) ioctl, by just calling the
> write_filemark function. (duh). With this change, amanda doesn't die
> trying to write a filemark.
And the call is probably not necessary anyway, as close() will write a
filemark on all current tape drivers.
Is that all you did to implement the function ? Did you think about
interlocking the read() and write() functions with this ioctl() ?
...
Since you have the energy, why don't you find a copy of QIC-157 and
grab the mtops code from the st driver and see about squeezing it into
pt. If you can keep the changes to the existing code to a minimum, we'll
probably use it.
--------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
--------------------------------------------------------------------------
-- 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:48 EST