On Tue, 18 Apr 2000, Eric Lee Green wrote:
> Kai Makisara wrote:
> > 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).
>
> You should also be reluctant to do so because it would break all commercial
> tape backup software for Linux. EST, Knox Software, Computer Associates Inc.,
> etc., would all be somewhat upset if one day somebody made their software
> break. Changes to Linux that make commercial software break is already a
> long-time problem, otherwise there would not be a Linux Standard Base project.
> Whatever your feelings on commercial software, until there are Open Source
> alternatives of equal capability, the success of Linux depends upon it.
>
I don't want to break commercial software or old binaries. The changes don't
break binaries if the changes are done properly: The current MTIOCGET
ioctl is renamed to OLDMTIOCGET (or something else) and a new ioctl
MTIOCGET is defined (with a new ioctl number). Code is added to all tape
drivers to translate the OLDMTIOCGET operation codes to new MTIOCGET codes
before they are interpreted. After this old and new binaries work
properly. This basic mechanism has been widely used in Linux and
elsewhere.
However, rmt would still be a problem during the transition period even
between Linux boxes. The transition period will be a long one because the
changes must propagate from the kernel through glibc and distributions to
end users.
Another possibility is to provide an rmt that does the translation. If
someone knows a mechanism for rmt to know if it is talking to a Linux
machine or a non-Linux machine, this would be a nice solution...
...
> > I have not seen a proper definition for the Unix tape semantics. It seems
>
> http://www.opennc.org/pubs/catalog/t912.htm
>
> Hmm, a search does not show any entry for 'mtio' in the Single Unix
> Specification. I guess that puts the whole MTIO ioctl stuff into the realm of
> "system dependent". Any utility which makes assumptions about what "magic
> numbers" are for those ioctls is, therefore, by definition, broken.
>
> > 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.
>
> I would not say "free". It would be interesting to see how, say, Solaris,
> returns this information (Solaris being the #2 most popular Unix platform,
> after Linux). On the other hand, given that the information currently isn't
> being returned at all, adhering slavishly to the Solaris way of doing things
> isn't necessary.
>
Solaris provides the MTIOCGETDRIVETYPE ioctl but it does not include, for
instance, the block size limits.
None of the Unix mtio definitions I have seen provides an ioctl for
getting device information that I would like to use in Linux.
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
