need help with multi-reel cpio

[Greg Noel]

In article <236 at nyit.UUCP> rick at nyit.UUCP (Rick Ace) writes:
>Doug Gwyn writes:
>> I prefer Greg's suggestion over Griff's.  There seem to me to be
>> two ways to handle magtapes on UNIX:  (a) make them do the right
>> thing to fit the generalized idea of "file";  (b) supply special
>> magtape-handling bells and whistles.

Hmmmmm.....  I didn't know our suggestions were opposed.  I was arguing for
minimum semantics that were compatible with the rest of the industry.  Griff
and Rick are arguing that more complete semantics should be provided.  The
ideal probably would be to have the minimum semantics \required/ as part of
the standard, but have the "bells and whistles" be present only if the actual
transport was capable of it (i.e., you'd have to check the return value of
the ioctl (or whatever) to be sure that your action was executed).

>> ........  But whatever approach is used,
>> it should be done RIGHT, which has not traditionally been the
>> case with UNIX magtape drivers.

Yea, verily.  It would also require some careful thought to be sure that most
of the operations could be simulated on transports that cannot do all of the
"standard" functions.  That's why I think a standard for (a) would be more
likely than a standard for (b).

>If you have method (b) only, you can simulate method (a) in user-mode
>code.  The reverse is not necessarily true.

Maybe.  But is is worth it?

>All tape drives I've met support these primitive operations:
>	Read physical record (or tape mark) and return its length
>	Write physical record of software-specified length (before,
>	 at, and after the EOT reflector)
>	Write tape mark (before, at, and after the EOT reflector)
>	Rewind
>	Detect transition into the EOT region (the tape beyond the reflector)
>UNIX magtape drivers should offer these functions as a bare minimum.

Yes, with the semantics that you get a write error in the EOT region, and the
record is \not/ \written/.  The only things that you should be permitted to do
at this point are close, rewind, or possibly issue an ioctl to permit one more
block to be written.  (And if you do rewind without closing, the driver should
ensure that EOFs are written.)

>Supporting the generalized notion of a "file" is also useful, but
>there are some instances where you want to tell the operating system
>to get out of the way and provide "hands-on" access to the tape.

I agree, but I think the one-way file semantics are the minimal set that
should be provided, with the hands-on fiddling as extensions.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg at ncr-sd.UUCP or Greg at nosc.ARPA