On 15-01-29 07:56 PM, Andy Grover wrote:
This will enable user programs to have access to the most current
definitions.
The above description is a bit too generic.
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.
So is this delayed regression likely to happen?? Do we need to
speak to the glib folks?
What is the appropriate include for a user space program to fetch
sg.h in its new (proposed) location?
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).
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).
Doug Gilbert
--
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
