On Fri, 2015-01-09 at 18:11 +0100, Christoph Hellwig wrote: > On Fri, Jan 09, 2015 at 08:33:00AM -0800, James Bottomley wrote: > > Yes, but they have to be delivered to users somehow. If you look at > > debian, they deliver the headers through the linux-dev-libc package > > which installs into the /usr/include directory. > > linux-libc-dev despite the name is provided from the kernel source package: > > https://packages.debian.org/sid/linux-libc-dev I know ... I actually took a look in the source to see if they'd commented why they weren't including any SCSI files ... it's not just the clashing files, it's also things like scsi/fc. The reason is that glibc is slowly incorporating those. So first question is: do we want to supply the linux-libc-dev package or are we happy with the glibc route? > > Since glibc currently > > owns the entirety of /usr/include/scsi, we have to help the distros > > figure out how we deliver the headers, otherwise all uapi exports of > > SCSI stuff just gets ignored ... > > That's why I've been arguing for adding a new linux/scsi_ioctl.h header > to bypass that whole conflict since my first mail in this thread. If we go that route, I have a marginal preference for the linux/scsi/ namespace. We still also need a co-existence and transition plan, because if we don't export the opcodes, glibc is going to have to supply them in scsi/scsi.h anyway and we're going to have to not clash with some of its extraneous definitions, like device types, status codes and some ioctls. 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
