scsi: consistent use of __u8 in scsi/scsi.h
PATCH 1/1 scsi: consistent use of __u8 in scsi/scsi.h
scsi/scsi.h is exported to userspace, so it should use __u8 instead of u8 as other userspace-visible headers do.
This fixes the following errors when application includes scsi/scsi.h
generated with make headers_install:include/scsi/scsi.h:145: error: expected specifier-qualifier-list before ‘u8’ include/scsi/scsi.h: In function ‘scsi_varlen_cdb_length’:include/scsi/scsi.h:156: error: ‘struct scsi_varlen_cdb_hdr’ has no member named ‘additional_cdb_length’
--- include/scsi/scsi.h | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
include/scsi/scsi.h +4 -4
@@ -142,10 +142,10 @@ struct scsi_cmnd;/* defined in T10 SCSI Primary Commands-2 (SPC2) */ struct scsi_varlen_cdb_hdr { -u8 opcode;/* opcode always == VARIABLE_LENGTH_CMD */ -u8 control; -u8 misc[5 ]; -u8 additional_cdb_length;/* total cdb length - 8 */ +__u8 opcode;/* opcode always == VARIABLE_LENGTH_CMD */ +__u8 control; +__u8 misc[5 ]; +__u8 additional_cdb_length;/* total cdb length - 8 */ __be16 service_action;/* service specific data follows */ };
Signature · 5 lines
1.6.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
James Bottomley
maintainerQuoted 2 lines · Michael S. Tsirkin
scsi/scsi.his exported to userspace, so it should use__u8instead of u8 as other userspace-visible headers do.
Actually, can we just put a hold on this until we decide what we're doing with exporting include/scsi.
Arguments so far are
1. Don't export and let glibc supply the headers (as it does now)
2. Move headers to be exported to include/linux
3. Take over include/scsi export from glibc: this will necessitate comparing our current headers and those of glibc and moving stuff around.
James
Quoted 7 lines · James Bottomley
Quoted 2 lines · Michael S. Tsirkin
scsi/scsi.his exported to userspace, so it should use__u8instead of u8 as other userspace-visible headers do.Actually, can we just put a hold on this until we decide what we're doing with exporting
include/scsi.
Quoted 8 lines
Arguments so far are
1. Don't export and let glibc supply the headers (as it does now)
2. Move headers to be exported toinclude/linux
3. Take overinclude/scsiexport from glibc: this will necessitate comparing our current headers and those of glibc and moving stuff around.
I'm all for 3. I think if done we should do it for all include/scsi at once. No need for prolonged pain.
[]$ ls /usr/include/scsiscsi.hscsi_ioctl.hscsi_tgt_if.hsg.h
However I'll have to ask my employers if they can spare me, so any other volunteers?
TODO:
* Fix up Kernel headers by complying to check_headers
* Test drive some example user-mode applications including glibc itself.
* send patches to glibc
* send patches to Kernel
* Notify distributions.
Quoted 2 lines
James
Boaz
Quoted 7 lines · James Bottomley
Quoted 2 lines · Michael S. Tsirkin
scsi/scsi.his exported to userspace, so it should use__u8instead of u8 as other userspace-visible headers do.Actually, can we just put a hold on this until we decide what we're doing with exporting
include/scsi.
Quoted 7 lines
Arguments so far are
1. Don't export and let glibc supply the headers (as it does now)
2. Move headers to be exported toinclude/linux
3. Take overinclude/scsiexport from glibc: this will necessitate comparing our current headers and those of glibc and moving stuff around.
2 + 3...
Let include/scsi be kernel internal stuff.
And have the exported headers in include/linux.
This is how net/ handle their headers.
I did a quick diff of the glibc provided scsi.h and kernel scsi.h.
Quoted 1 line
From a quick look it seems that we have more in the kernel version
than the glibc version - and no obvious conflicts.
But agree with Boaz that we should do this in one go.
Sam
James Bottomley
maintainerQuoted 16 lines · Sam Ravnborg
Quoted 7 lines · James Bottomley
Quoted 2 lines · Michael S. Tsirkin
scsi/scsi.his exported to userspace, so it should use__u8instead of u8 as other userspace-visible headers do.Actually, can we just put a hold on this until we decide what we're doing with exporting
include/scsi.Quoted 7 lines
Arguments so far are
1. Don't export and let glibc supply the headers (as it does now)
2. Move headers to be exported toinclude/linux
3. Take overinclude/scsiexport from glibc: this will necessitate comparing our current headers and those of glibc and moving stuff around.
Quoted 3 lines
2 + 3...
Letinclude/scsibe kernel internal stuff.
And have the exported headers ininclude/linux.
I don't quite understand what you're saying here. I think 2 and 3 are either/or options. Either we move the exported files to include/linux or we export from include/scsi.
I have to say I don't like option 2 because the breakage is visible to user level programs (unless we can persuade glibc people to #include <linux/scsi.h> in scsi/scsi.h).
Quoted 7 lines
This is how
net/handle their headers.I did a quick diff of the glibc provided
scsi.hand kernelscsi.h.Quoted 1 line
From a quick look it seems that we have more in the kernel version
than the glibc version - and no obvious conflicts.
But agree with Boaz that we should do this in one go.
James
Quoted 17 lines · James Bottomley
Quoted 16 lines · Sam Ravnborg
Quoted 14 lines · James Bottomley
Quoted 2 lines · Michael S. Tsirkin
scsi/scsi.his exported to userspace, so it should use__u8instead of u8 as other userspace-visible headers do.Actually, can we just put a hold on this until we decide what we're doing with exporting
include/scsi.Arguments so far are
1. Don't export and let glibc supply the headers (as it does now)
2. Move headers to be exported toinclude/linux
3. Take overinclude/scsiexport from glibc: this will necessitate comparing our current headers and those of glibc and moving stuff around.
Quoted 7 lines
Quoted 3 lines
2 + 3...
Letinclude/scsibe kernel internal stuff.
And have the exported headers ininclude/linux.I don't quite understand what you're saying here. I think 2 and 3 are either/or options. Either we move the exported files to
include/linuxor we export frominclude/scsi.
That we should in any case look at what glibc have defined in their respective headers when we prepare the kernel versions for export.
Quoted 4 lines
I have to say I don't like option 2 because the breakage is visible to user level programs (unless we can persuade glibc people to #include <
linux/scsi.h> inscsi/scsi.h).
We could turn this the other way around...
glibc could add a wrapper file when they are ready to rely on the kernel version.
So userspace continue to work independent of glibc using their own set of headers for scsi or they use the kernel supplied headers via the wrapper header file . Just an idea.
It would be bad if userspace had to do something strange to pick up scsi.h in scsi/ for some glibc versions and from linux/ for other glibc versions.
Sam
Quoted 2 lines · Boaz Harrosh
TODO:
* Fix up Kernel headers by complying tocheck_headers
This is accomplished by applying the following on top of my previous patch:
Subject: scsi: make scsi/scsi.h headers_check clean
place extern declarations in scsi/scsi.h within ifdef __KERNEL__ so that make headers_install strips them out.
--- include/scsi/scsi.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
include/scsi/scsi.h +4 -0
@@ -150,6 +150,7 @@ struct scsi_varlen_cdb_hdr {/* service specific data follows */ }; +#ifdef __KERNEL__static inline unsigned scsi_varlen_cdb_length (const void *hdr) {
@@ -165,6 +166,7 @@ scsi_command_size(const unsigned char *cmnd)return (cmnd[0 ] ==VARIABLE_LENGTH_CMD ) ? scsi_varlen_cdb_length(cmnd) : COMMAND_SIZE(cmnd[0]); } +#endif /* * SCSI Architecture Model (SAM) Status codes. Taken from SAM-3 draft
@@ -281,8 +283,10 @@ enum scsi_protocol { SCSI_PROTOCOL_UNSPEC = 0xf, /* No specific protocol */ }; +#ifdef __KERNEL__/* Returns a human-readable name for the device */ extern const char *scsi_device_type (unsigned type); +#endif /* * standard mode-select header prepended to all mode-select commands
Signature · 1 line
1.6.2.5
Quoted 3 lines · James Bottomley
3. Take over
include/scsiexport from glibc: this will necessitate comparing our current headers and those of glibc and moving stuff around.
Speaking of which: is there a chance some userspace still depends on SCSI_IOCTL_TAGGED_{ENABLE,DISABLE} being defined (even though they don't work) ? glibc headers have them ...
Quoted 7 lines · Michael S. Tsirkin
Quoted 2 lines · Boaz Harrosh
TODO:
* Fix up Kernel headers by complying tocheck_headersThis is accomplished by applying the following on top of my previous patch:
This is not enough. The same should be done to the other 3 include/scsi headers I mentioned and export them.
<snip>
Boaz
Quoted 19 lines · James Bottomley
Quoted 9 lines · Sam Ravnborg
Quoted 8 lines · James Bottomley
Quoted 2 lines · Michael S. Tsirkin
scsi/scsi.his exported to userspace, so it should use__u8instead of u8 as other userspace-visible headers do.Actually, can we just put a hold on this until we decide what we're doing with exporting
include/scsi.Arguments so far are
Quoted 8 lines
Quoted 5 lines
1. Don't export and let glibc supply the headers (as it does now)
2. Move headers to be exported toinclude/linux
3. Take overinclude/scsiexport from glibc: this will necessitate comparing our current headers and those of glibc and moving stuff around.2 + 3...
Letinclude/scsibe kernel internal stuff.
And have the exported headers ininclude/linux.
Quoted 8 lines
I don't quite understand what you're saying here. I think 2 and 3 are either/or options. Either we move the exported files to
include/linuxor we export frominclude/scsi.I have to say I don't like option 2 because the breakage is visible to user level programs (unless we can persuade glibc people to #include <
linux/scsi.h> inscsi/scsi.h).
This is, to me, a definition of a mess. Please (very strongly) don't do that. The file is scsi/scsi.h and that's it.
I don't know for a fact but I can imagine that there was a time that Kernel did not export any headers and glibc would sample a set every release. At some point in time a kind soul decided that Kernel Headers should be exported from the Kernel package and the rest is history. But he forgot that include/scsi/ is also included. Lets just fix his simple mistake and fix this by taking back control of Kernel headers.
Quoted 2 lines
Quoted 2 lines
This is how
net/handle their headers.
If it was done so originally, but now these headers are scsi/*.h, it's to late.
Quoted 4 lines
Quoted 4 lines
I did a quick diff of the glibc provided
scsi.hand kernelscsi.h.Quoted 1 line
From a quick look it seems that we have more in the kernel version
than the glibc version - and no obvious conflicts.
exactly it is original Kernel headers from the time they where sampled last by glibc.
Quoted 6 lines
Quoted 1 line
But agree with Boaz that we should do this in one go.
James
Boaz
Quoted 7 lines · Boaz Harrosh
Quoted 4 lines
Quoted 4 lines
I did a quick diff of the glibc provided
scsi.hand kernelscsi.h.Quoted 1 line
From a quick look it seems that we have more in the kernel version
than the glibc version - and no obvious conflicts.
exactly it is original Kernel headers from the time they where sampled last by glibc.
glibc also added
#include <features.h>
in some of them.
Donnu why.
Quoted 5 lines · Boaz Harrosh
[]$ ls
/usr/include/scsiscsi.hscsi_ioctl.hscsi_tgt_if.hsg.h
$wget http://ftp.gnu.org/gnu/glibc/glibc-2.10.1.tar.bz2
$cd glibc-2.10.1
$find . -name scsi ./sysdeps/unix/sysv/linux/scsi
$ls ./sysdeps/unix/sysv/linux/scsi/scsi.h scsi_ioctl.h sg.h
where did you get scsi_tgt_if.h?
Quoted 11 lines · Boaz Harrosh
Quoted 7 lines · Michael S. Tsirkin
Quoted 2 lines · Boaz Harrosh
TODO:
* Fix up Kernel headers by complying tocheck_headersThis is accomplished by applying the following on top of my previous patch:
This is not enough. The same should be done to the other 3
include/scsiheaders I mentioned and export them.
Right. Well, that's easy enough, isn't it?
Subject: scsi: export scsi_ioctl.h and sg.h headers
glibc uses scsi/sg.h and scsi/scsi_ioctl.h, so we need to export these headers.
--- include/scsi/Kbuild | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
include/scsi/Kbuild +2 -0
@@ -1,3 +1,5 @@ +header-y += sg.h +header-y += scsi_ioctl.h header-y += scsi.h header-y += scsi_netlink.h header-y += scsi_netlink_fc.h
Signature · 1 line
1.6.2.5
Quoted 6 lines · Michael S. Tsirkin
Quoted 5 lines · Boaz Harrosh
Quoted 4 lines
Quoted 4 lines
I did a quick diff of the glibc provided
scsi.hand kernelscsi.h.Quoted 1 line
From a quick look it seems that we have more in the kernel version
than the glibc version - and no obvious conflicts.
Quoted 7 lines
Quoted 2 lines
exactly it is original Kernel headers from the time they where sampled last by glibc.
glibc also added
#include <features.h>
in some of them.
Donnu why.
Browsing features.h this looked unused (by scsi.h) to me.
Sam
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines · Boaz Harrosh
[]$ ls
/usr/include/scsiscsi.hscsi_ioctl.hscsi_tgt_if.hsg.h
Quoted 8 lines
$wget http://ftp.gnu.org/gnu/glibc/glibc-2.10.1.tar.bz2
$cd glibc-2.10.1
$find . -name scsi ./sysdeps/unix/sysv/linux/scsi
$ls ./sysdeps/unix/sysv/linux/scsi/scsi.hscsi_ioctl.hsg.hwhere did you get
scsi_tgt_if.h?
You're right I have it from the SCSI target framework (tgt)
(http://stgt.berlios.de/)
It is a Kernel header that should be exported, I'll send a patch to export it.
Thanks
Boaz
Quoted 6 lines · James Bottomley
Quoted 2 lines · Michael S. Tsirkin
scsi/scsi.his exported to userspace, so it should use__u8instead of u8 as other userspace-visible headers do.Actually, can we just put a hold on this until we decide what we're doing with exporting
include/scsi.
Any update?