On Sun, 8 Aug 1999, Kai Makisara wrote:
> It is not clear to me whether the st driver should implement its own
> llseek() that returns ESPIPE or use the default as it does now. The man
I think so. I can see two approaches:
I-do-everything-approach:
- it accepts any seek, and attempts to implement it
- first by using LOCATE (ie DDS-2, the ioctl() you proposed)
(this can go backward or forward, but this can fail e.g.
if tapes doesn't support, if scsi2logical not set, etc)
- then by rewinding and spacing forward or reading, or
just reading if you seek forward
Advantage: allows to treat a tape like a file, with a very good
compatibility.
Disadvantage: not portable, puts a lot of stuff in the kernel.
I-fail-if-I-can't-approach:
- forward seeks are implemented either with ioctl() or with dummy
reads, depending maybe on a mt stoptions
- all others are rejected with ISPIPE
I-fail-always-approach:
- all are rejected with ISPIPE: please use the low-level move commands
manually (ioctls()).
The current implementation, for me, is wrong: it fails silently, really.
> I am willing to change the lseek() behaviour of the st driver if someone
> gives me a strong enough reason. However, note that relying on the
> behaviour of lseek() with tapes in general is bad because the behaviour
> may not be consistent across Unix and Unix-like systems.
You are right. It's really not that important. You can leave it as is,
although I would prefer to simply implement lseek() on tapes as
an error (ISPIPE), so that trivial errors are spotted easily.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
