You are stuck within user land... there is the kernel (st), the scsi driver,
and the hardware that can (and do) independently keep state information.
The drive will (or at least _should_) know that the tape you inserted is
unreadable - period. The only commands it will allow in such a state is
generally rewind, retension (on a good day), unload, and format.
>The tape gets changed. Open has still not got called because nobody
>is accessing the tape. Therefore nobody "knows" that the tape has been
>changed, even though the drive "remembers".
Upon opening the device, the driver will send a "test unit ready" command
to the drive to verify the state of the tape. It may not have any other
indication of changes to the medium, bus, or hardware. (tape change,
scsi bus reset for what ever reason, or external hardware reset.)
The answer to the test unit command will direct what the driver does next.
It is here that the driver _may_ see a "unit attention." According to the
spec. the driver is required to request sense data to see what the drive
is attempting to indicate. The sense information will indicate if the
media has been changed, the bus has been reset, or the device has been reset
(among other things.)
With the (older?) st driver built with debugging turned on, it will dump the
tape information (mode sense data?) when it sees a new tape loaded. And the
driver does reset its state when it knows the media has changed.
>Several hours/days/months later, open is called by a new tape user.
>Is this user going to get errors reported during a previous tape
>session? Or is this user going to get a Unit attention "error" when,
>in fact, no error for a completely new session, with a completely new
>tape, has occurred.
If a session is defined as the time from open to close, then no. Each session
is independant. The only state information maintained between sessions is the
tape type and position (and the like.) However, if an error terminated the
previous session and no one has done anything to address it, then you are
likely to get the same error again. For example, writing to a full tape.
>I think that a tape can only be "changed", while a fd is open. Whatever
>happens when the tape-drive is not in-use, i.e., physically changing the
>media, etc., should (logically) be ignored. In other words, a new open
>should do whatever is neccessary to remove all previous history of the
>drive's use.
Yes and no... the driver will only know the tape was changed WHEN it is asked
to open the tape again (no async notification; the only thing on the bus that
is supposed to initiate commands in the scsi controller. [there are exceptions
known as "target mode", but I won't get into that unless you want me too :-)])
--Ricky
PS: I modified the st driver a few times some months (years) ago to make things
work better for me. I have three tape drives on a linux machine. That many
drives running at the same time can cause buffering problems (i.e. not enough
memory for them <grin>) I also had to "correct" the mtio.h magic numbers to
stop other (sunos, solaris, ultrix, irix, ???) OSes from doing bad things to
my tapes (like erasing them, eject them, etc.)
PPS: A word on st as a module... I like it and I use it. Of course, I tend
to load it at boot and leave it loaded. Having it as a module allows me to
fix problems and other wierdness without having to reboot the machine (most
of the time.) I have it loaded as close to the beginning of the boot sequence
as I can get it so it has "first choice" at precious buffer space. It's hard
to grab 6 - 128k buffers once X starts up :-)