On Fri, 2015-01-09 at 16:46 +0100, Christoph Hellwig wrote: > 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. Right, that's why I'm dubious about this effort. uapi files either have to become the glibc headers or be exported in a way that allows inclusion into glibc headers for there to be any point. > 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. Agreed, but I think we need to start with the glibc people first to find out how they want our uapi exports structured so they can replace part of the copy they have. James -- 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
