Re: Fixes for the ide-tape driver

[Alan Stern]

On Sun, 3 Nov 2002, Jens Axboe wrote:

> On Sat, Nov 02 2002, Alan Cox wrote:
> > Thanks for the 2.5 bits. For the 2.4 tree send them on to Marcelo after
> > 2.4.20 is out. You might also want to talk to Pete Zaitcev
> > <[e-mail]> as I know he posted some fixes too recently
>
> The use of IDETAPE_RQ_CMD looks shady, at best. And idetape_do_request()
> does a direct switch() on the flags, ugh.

I agree, absolutely.  Those are the least of this driver's stylistic
infelicities.  The two things I have found to be most objectionable are:

First, the driver is a mish-mash, including code for handling OnStream
devices along with generic ATAPI devices.  In some places the specialized
code is set off with regular conditional tests, in others by pre-processor
conditionals, and in others not at all.  Willem Riede has expressed his
intention to write a different driver just for the OnStream, which I think
is a very good idea.

Second, the use of write buffering means that the driver is unable to
detect and report end-of-media or other write errors until they occur,
long after returning successfully from the corresponding system call.
Considering that tape drives are often used for backups, this lack of
proper error-reporting is not appropriate for such a mission-critical
application.  (This was a conscious decision on the part of the original
author of the driver.  There is supposed to be support for compiling it
without the write buffer, but -- presumably as a result of later changes
-- it doesn't work.)

My version of the driver is not perfect.  For example, I know (because I
have seen it happen) that the driver can hang when encountering a
faulty-media error.  All I have done is add a more-or-less minimal number
of changes that suffice to make the driver work okay on my system, and
hence presumably for other ATAPI systems as well.  It might be nice to
make larger-scale changes, but I don't have the time or the desire to do
so.

Alan Stern