On Tue, 16 Nov 1999, Stephen Harris wrote:
> I hope the scsi list is the place to talk about ioctl() parameters for
> tape devices in mtio.h - if not please suggest a better place...
> The source _is_ scsi/st.c :-)
>
The linux-tape would be better but this is OK for this discussion (all
tapes with different interfaces use mtio.h where applicable).
> Precis of problem:
> I've been having trouble getting "ufsrestore" to work between a Solaris 7
> box and a Linux 2.0.x system. The error reported was about an incompatible
> rmt problem, but tracing the problem further showed that the results
> from MTIOCGET was causing the problem.
>
... The text displaying different definitions of struct mtget in Solaris
... and Linux clipped.
Any program that uses the rmt ioctl capabilities either
- assumes that all systems originate from company xxx, or
- translates the returned structure based on knowledge about the
remote system, or
- gets into trouble
The basic problem is that the rmt S command fetches the binary structure.
Even if the struct definitions between Solaris and Linux would agree, the
different byte orders would cause problems.
> (hmm, just checked a 2.2.12 kernel and it appears the same, I don't
> currently have a 2.3 system in working order).
>
2.3 has the same definition.
...
> This means that a Linux system can not act as a tape host to a Solaris 7
> machine.
>
There are many other systems not compatible with Solaris ufsdump if it
uses the binary status data.
What can be done is to write an rmt that identifies the remote system
and does the necessary translation (I and S commands). The sources for one
version of rmt can be found in the sources of dump.
> Is there any reason for this difference?
>
The basic reason seems to be that there is not a standard for the
definitions for tape operations (at least I have not seen such).
The definitions in mtio.h are not meant to be used across different
systems (for instance, the byte order is not defined, mtio.h lives in
/usr/include/sys, ...).
I have nothing against changing the definitions (in the proper way not to
break Linux userspace) when someone designs new definitions and convinces
me that the new definitions are as universal as possible ;-)
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
