Re: [PATCH 2/3] scsi: Move user-shareable stuff in scsi/scsi.h to uapi/scsi/scsi.h

[Christoph Hellwig <hch@lst.de>]

On Fri, Jan 09, 2015 at 07:27:46AM -0800, James Bottomley wrote:
> Actually, they are exported.  If you look at what glibc supplies, it has
> it's own copies of scsi.h and scsi_ioctl.h.  If we try to repace those
> with uapi, we have to make sure nothing breaks, so the opcodes have to
> be in scsi.h somehow.
> 
> Now, I agree that the opcodes in our scsi.h shouldn't be the definitive
> ones because they're the only the ones the kernel cares about.  However,
> the fact is that any userspace programme including scsi.h and
> scsi_ioctl.h is expecting to get the opcodes and we can't break that.
> 
> Were you thinking of moving opcodes to scsi_opcodes.h and #including
> that in scsi.h but not exporting it so glibc supplies its own?

I don't think trying to replace glibcs fork of our scsi/*.h is
a good use of our time.  They will have keep it complatible with
their old version anyway.  So they will still have to provide their
old subset of operations.

What does however make sense is to export our ioctl ABI.  As with
most other ioctls we should do that through and UAPI linux/*.h file,
e.g. linux/scsi_ioctl.h.  On our side it will replace the existing
ioctl defintions, and if we're careful glibc can also use it include
it from their files.  Trying to export all the opcodes, device types,
SCSI-2 messages and similar on the other hand is a lot of pain for
little gain.

Oh, and we also should have a uapi/linux/sg.h for the ioctls that
came from the sg driver.