like a no-rewind device. Secondly figure out whether the initial TUR
for a CTRL_MODE open resulted in a tape being actually found (if so,
then do a mount session).
Move the 'sun compatibility' behaviour into stdone && stclose- don't
mark a tape as having been written in stopenm, fer gosh sakes.
>We're not Linux. If we still want driver version strings to be displayed
>at boot, then I suppose DEBUG is a reasonable compromise.
Makes the whole concept useless. This is for default printouts. If you
can build a debug kernel, you know what version you have. This was under
the concept of 'RAS' so that hapless users could tell you microversion
things. But I guess this isn't the right way according to our local
Jesuits. Oh, well. I'll think up something different and hopefully
less objectionable. And yes, NetBSD isn't linux. The developers seem
to be equally bad tempered, but linux is more successful.
Part B:
Field interrupts in OS layer so that (in this OS) bus_dmamap_sync(POSTREAD)
can (formally) ensure that the result queue is stable wrt to buffering
and that for sending a command a bus_dmamap_sync(PREWRITE) is done to
ensure that the device gets a good view of what the mailbox contents
should be.
>at boot, then I suppose DEBUG is a reasonable compromise.
Makes the whole concept useless. This is for default printouts. If you
can build a debug kernel, you know what version you have. This was under
the concept of 'RAS' so that hapless users could tell you microversion
things. But I guess this isn't the right way according to our local
Jesuits. Oh, well. I'll think up something different and hopefully
less objectionable. And yes, NetBSD isn't linux. The developers seem
to be equally bad tempered, but linux is more successful.
machdep.c retains the `mainbus' (i.e. sun4/sun4c) bus_dma* versions for now.
Create a DVMA map specifically for 24-bit devices (le,ie), which has a
more room than previous DVMA map which should be reserved for sun4 VME.
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.
