On Mon, 17 Apr 2000, Ricky Beam wrote:
> On Mon, 17 Apr 2000, Eric Lee Green wrote:
> >> Most mtio type ioctls are already non-portable.
> >
> >But most of them can be "wrapped" to present a coherent interface to
> >applications software. Unfortunately, this ends up being a
> >least-common-denominator type approach, where the "wrapper" function can only
> >take advantage of those capabilities available on all involved platforms. I
> >suspect Kai was mostly saying that adding too much stuff to the mtio ioctl
> >would not help most applications due to those portability issues.
>
> 'rmt' handles most of the tape I/O -- at least the ones that matter (local
> binaries are irrelevant.) It cannot tell what platform is sending it data.
> So, either you make everyone else on the planet do things "the linux way"
> or you follow the defacto standard scheme and go about your business.
>
Ricky,
you are talking about the MTIOCTOP operation codes which is a different
problem. It is true that the codes Linux uses are different from what most
other systems are using. I suppose the Linux definitions have come from
some existing system but I don't know which one.
The Linux codes should be changed at some time. However, I am reluctant to
do that until someone presents a list of codes and explanation why the list is
correct (also beyond code 7).
(rmt is a broken protocol: it uses system-dependent numbers to transfer
commands from one system to another. Actually we should fix rmt instead of
the Linux definitions ;-)
I have not seen a proper definition for the Unix tape semantics. It seems
that some things seem to be supported by most systems. These include the
ioctls MTIOCTOP (the most common operations), the first few fields of
struct mtget returned by MTIOCGET and maybe MTIOCPOS. For anything beyond
this every system seems to have its own definitions. This is the area we
have been discussing in this thread. Since there is no common practice, we
are free to think what is the proper way to return this kind of
information.
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
