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.
>I like the notion of /proc entries. For static information like, e.g., max
>block size, that doesn't change for a drive during the time that it is active
>in the SCSI subsystem, this is a perfect place to stick it. Then we can leave
>the mtio status call for dynamic stuff that can change during the lifetime of
>the device, like what the current fixed block size is. Not cross-platform
>portable, of course, but then the mtio stuff isn't either.
Again, how will a remote system get this informaion? The ioctl() structures
are there for a reason; don't try to reinvent the wheel just because you don't
like it's color.
--Ricky
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
