Also- to be fair and on review, kern/391 isn't really addressed by
the previous commits. In reviewing, I'm embarassed to find that this
talks about reading at EOT. I'm actually going to claim that this
is 'not a bug' or 'fixed already' in that at the end of media (at the
edge of recorded media), you may continuously open the tape (should
you choose to) issue a read, and zero bytes will transfer- this is a
sufficient EOF indicator.
a now unused variable. Also, remove the restriction against at density
code being greater than the max SCSI 2 density code: 0x80..0xff are the
Vendor Unique codes and most certainly should be allowed. The check for
invalid values should be less than 0 or greater than 255.
Oh- yeah, the previous commit addressed kern/391.
EOM_PENDING. Set up a persistent EARLYWARNING behaviour flag. If
set, EOM behaviour forces a 'short read' to signal logical (as
opposed to physical) end of media. The user application may, of
course, do with this information what it will.
The EARLYWARNING behaviour may be enabled/disabled by a MTIOCTOP
operation. The default action is to not have EARLYWARNING enabled-
but this may be reversed by an option ST_ENABLE_EARLYWARN in
the kernel build.
interrupt context.
[I had some feline debugging help here. I noticed that every time Kem,
our kitty, jumped onto the USB keyboard the machine crashed.]
* attach arguments now directly support multiple register and
interrupt sets.
* address translation (`ranges') has been made bus-specific
* introduce sbus_destroy_attach_arg() to clean up after
attaching an an Sbus device.
The read/write system calls return ssize_t because -1 is used to indicate
error, therefore the transfer size MUST be limited to SSIZE_MAX, otherwise
garbage can be returned to the user.
There is NO change from existing behavior here, only a more precise
definition of that the semantics are, except in the Alpha case, where
the full SSIZE_MAX transfer size can now be realized (ssize_t is 64-bit
on the Alpha).
the former, but not the latter. Hopefully, this will address some problems
people have been experiencing w/ some devices on Pyxis systems when BWX
is used for bus access. (If it's not used for PCI config access, we can
get fatal machine checks while probing behind PCI-PCI bridges!!)
