[ On Monday, December 4, 2000 at 23:06:25 (-0800), Matthew Jacob wrote: ]
> Subject: Re: EXB-4200c, the continuing saga...
>
> There EIO arrors are the same as the've always been. If there's no tape
> loaded, you get an error. I thought we might have fixed it for control mode in
> NetBSD, but I guess not (FreeBSD works fine in this respect).

It may have been fixed since 1.5F -- I dunno, yet...

> It is offensive for you to claim that this isn't 'production' quality when you
> can't even be bothered to read the man page.

I read the manual page.  It says nothing directly about not being able
to open a "standard" mode (eg. /dev/rst0) device with no tape loaded.

It makes only indirect reference to being able to do so on the control
mode device (eg. /dev/erst0).

I make no apologies for what I said because what I said is true.

99.99% of the existing available tape handling software out there in the
world gets rather upset when an I/O error is returned on open, and that
includes all of NetBSD's own tools which currently still default to
opening the wrong device (given the state of driver today):

	src/include/paths.h:#define    _PATH_DEFTAPE   "/dev/nrst0"

EIO on read or write would be an entirely different story (which would
of course imply that the traditional ioctls used by 'mt', etc. would all
work with, or without, a tape loaded, regardless of the type of drive or
the specific sub-mode device opened).  This is especially bogus when
you're trying to deal with tape drives that take many tens of seconds to
get ready even after you've inserted a tape -- having to retry the open
until it works is simply bad design.

I.e. tape handling on NetBSD is definitely not anywhere near
"production" quality yet -- i.e. ready to use with available software
that expects de facto standard behaviour from the driver.  Even amanda
needs very careful configuration and patching to make it get by with
what NetBSD offers, especially when you're trying to run a tape library
on top of it all.

Tape drivers on some other systems that have worked much better for
these types of uses have always allowed the open to complete when the
drive is not ready and then blocked on read or write if the drive
indicates that it is busy loading, or returning EIO immediately if it is
not loading (or if the tape load fails, perhaps after some
driver-controlled timeout has expired after no response from the
device).

Some other systems have made a slightly different, but equally useful
(and perhaps more logically consistent), choice in how to deal with this
issue; namely to allow an open with O_NDELAY to succeed when the device
is not ready (and of course they've provided basic tools such as 'mt'
which use this flag when opening any specified device).  Such systems
usually also offer an ioctl that'll block until the state of the device
changes (i.e. until the state is different than the one the user-land
application believed it is in).  This way you can write a very simple
script like the following to deal with devices that need manual media
handling:

    status=$(mt status | fgrep ds=)
    if expr $status : '.*Mounted' > /dev/null ; then
        echo -n "Please eject the tape now... [waiting for status change] "
        mt wait unmounted
        echo "Thank you!"
    fi

(actually on SunOS-5.6, one such example system that uses O_NDELAY to
avoid EIO on opening a non-ready device, this script isn't yet possible
because the default system-supplied 'mt' doesn't yet have a command-line
option to call MTIOCSTATE.)

It should also be possible to explicitly reserve a tape device and not
have to rely on the semantics implied by whichever mode device is
opened, since it's otherwise impossible to share the device when using
just scripts to control things.  SunOS-5 provides this useful feature,
for example.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>