[ I'm late coming to this discussion as it was forwarded to me offlist- I've
  been unsubscribed for some months for reasons that are fairly well known.
  Hauke mailed this to me directly, so I'll come back to the list to express
  my opinion, FWIW. Sorry if this is not pertinent to the current
  discussion ]

>Date: Mon, 20 Sep 1999 21:16:30 +0200
>To: tech-kern
>From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
>Subject: scsipi/st.c issues
>
>I am in the middle of suggesting the st(4) driver to cooperate with
>Tandberg TDC 4222 and SLR 5 drives. While I am trying to make some sense of
>the code, a few questions come up:
>
>Quirks; in
>
>struct quirkdata {
>	u_int quirks;
>#define	ST_Q_FORCE_BLKSIZE	0x0001
>#define	ST_Q_SENSE_HELP		0x0002	/* must do READ for good MODE SENSE */
>#define	ST_Q_IGNORE_LOADS	0x0004
>#define	ST_Q_BLKSIZE		0x0008	/* variable-block media_blksize > 0 */
>#define	ST_Q_UNIMODAL		0x0010	/* unimode drive rejects mode select */
>	u_int page_0_size;
>#define	MAX_PAGE_0_SIZE	64
>	struct modes modes[4];
>};
>
>there is some global flag missing for dealing with QIC-like EOM handling

The global flag is ST_2FM_AT_EOD.

>(one filemark) in "quirkdata.quirks". Currently, a drive slips through the
>cracks in st_decide_mode() when it gets probed as running in "default
>mode", i.e. st->density == 0.

There is no quirk flag at present in NetBSD to turn off the 2FM@EOD behaviour.
It's still based solely on density as found in st_decide_mode (which is
often bogus until some media access occurs).

>
>As a result, newer QIC drives are nailed to 512 bytes fixed blocksize when
>they should be 1024 bytes or variable (what is preferable, btw., if you are
>free to choose?).

There's a lot of difference of opinion on this. In my opinion, the QIC
manufacturers have been so bad in their emulation of variable mode that
it's just downright wrongheaded to try and use it. Selecting 512 bytes
fiexed for < QIC-525 and 1024 fixed for the above seems reasonable.
Other folks feel that the emulated variable mode is fine and will
vehemently tell me that I'm suffering from acute ENOCLUE.

>Furthermore, you get two filemarks at EOM which prohibits
>tarring/dumping several files onto one tape - appending to a tape gives a
>flood of errors. This was broken around 1.3, it worked for me with a 1.2G
>kernel.

Is there a PR open on this?

>
>The drive- and density-related flags should be documented in st(4) or,
>better, in scsi_quirks(9).

Okay.

>
>What "page 0" is "quirkdata.page_0_size" referring to? The "vital product
>data" page length? And how would I determine the correct length for a given
>drive?

This is for drives that need a precise mode length, I believe. It doesn't
appear to be used anywhere. The comments ahead of st_mode_sense are
boguws- it's not an INQUIRY that's being sent but a Group 0 Mode Sense
(w/o a page code). The purpose of this is to get the current density,
the current block size, and whether the tape is write-protected.

I have an SLR5 and an HP TR-5 clone- If a PR is opened to remind me,
I'll do some checking on this stuff next week to see if these work
reasonably well. The other issues are "need quirk data to force
1FM@EOM" and "Document this stuff".

-matt