Re: [PATCHv2 5/5] scsi: move scsi/sg.h to uapi/linux/sg.h

[Andy Grover <agrover@redhat.com>]

On 01/30/2015 09:28 AM, Douglas Gilbert wrote:
> At the moment many user space programs in Linux access the SG_IO
> ioctl related declarations with:
>     #include <scsi/sg.h>
>
> I suspect that file is maintained by the glib folks (because it
> does not match the kernel file but is logically equivalent). Now
> if this change encourages those glib folks to break the above
> include (same applies to '#include <scsi/sg.h>') then that is
> a serious regression.

This is avoided by putting the new kernel-exported headers in linux/* 
instead of scsi/*. Then user programs could move to the new include over 
time, and the old glibc-provided one could be deprecated and eventually 
removed.

> So is this delayed regression likely to happen??

It shouldn't, given the different include path.

> Do we need to speak to the glib folks?

Yes for phase 2 (but CC'd) to get the glibc scsi/* headers deprecated 
and eventually removed, but phase 1 is the kernel exporting proper uapi 
headers, which have just gotten feedback for v2 and I'll be cranking out 
a v3 shortly.

> What is the appropriate include for a user space program to fetch
> sg.h in its new (proposed) location?

#include <linux/sg.h>

> For example my utilities currently use:
>     #include <linux/bsg.h>
> to fetch the bsg header but need some autotools magic to not break
> in the absence of that header (e.g. prior to around lk 2.6.30).

CCing dhowells; something similar would be needed for sg.h I imagine. To 
me it looks like scsi/{scsi, scsi_ioctl, sg}.h should maybe have been 
included in the scripted uapi changes (607ca46).

> Finally isn't the semi-flat nature of the uapi/linux directory
> asking for trouble? IOW why isn't there a uapi/linux/scsi
> directory?
>
>    # cd /usr/src/linux-3.19/include/uapi/linux/
>    # ls | wc
>      440     440    4350
>    # ls -p | grep "/" | wc
>       24      24     204
>
> The last command is counting directories (and really should
> be simpler than that).

I could see #include <linux/scsi/sg.h> as reasonable but I am just a 
worker bee on a quest to not have to define modern scsi opcodes in my 
userspace code.

Regards -- Andy