This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

   # 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]