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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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