From owner-freebsd-scsi  Sun Jan 14 05:10:18 1996
Return-Path: owner-freebsd-scsi
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id FAA04323
          for freebsd-scsi-outgoing; Sun, 14 Jan 1996 05:10:18 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA04306
          Sun, 14 Jan 1996 05:10:01 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA05690; Mon, 15 Jan 1996 00:06:01 +1100
Date: Mon, 15 Jan 1996 00:06:01 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199601141306.AAA05690@godzilla.zeta.org.au>
To: freebsd-scsi@freefall.freebsd.org, gibbs@freefall.freebsd.org
Subject: Re: Calling st_unmount for nrst* devices
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk

>I don't like the fact that after closing the nrst* devices, we
>don't reenable the eject button.  In fact, although I haven't
>tracked down exactly why, even if you rewind the tape via an "mt
>rewind" after doing some operations on the nrst* devices, the drive
>is still locked.  I think  these patches fix the problem, but I'll

Isn't this behaviour a fundamental part of the idea of a "mount
session"?  See st.4.

Perhaps there should be another special minor or 3 to give modes
with different eject behaviour.  OTOH, there may already be too many
minors and too many variations to control with minor bits.  Perhaps
more emphasis could be placed on using the control minor (or direct
ioctls) to set local preferences.  This approach seems to work OK
for ttys.  Perhaps it could be improved by adding a standard devices
and more programmable sub-devices:

mode 0: Factory defaults.  Not programmable.  Use for portability.
modes 1-n: Local defaults.
mode n+1: (if ioctls aren't used) control device.

Bruce