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. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
