[PATCH] SCSI: userspace cannot use scsi_device_type

[PATCH] SCSI: userspace cannot use scsi_device_type

[Jeff Smith]

The following patch fixes the 'make headers_check' warning:
    include/scsi/scsi.h:288: userspace cannot call function or variable defined in the kernel
It is similar to a patch from Jaswinder Singh Rajput back in July, which did not initially compile.

I have compiled this patch, and as expected it generates the same kernel code with and without,
modulo the confusion caused by printk pollution that uses __DATE__ and __TIME__ and compressions
thereof. This indicates that the patch is harmless to apply from the kernel's POV. A search on google
and google/codesearch indicated that there is no obvious userland use of the scsi_device_type
identifier in a way that depends on the scsi.h code.

A similar patch for the scsi_command_size code should be feasible, but a code search reveals some 
explicit use of the include file for the command_size definitions, in OpenAFS in particular,
so I figure that should be submitted as a separate patch (or more likely, RFC) after I have 
worked through the usages I can see (none of which, in theory, should be valid anyway) and 
after any comment on this patch.

Jeff

Signed-off-by: Jeff Smith <lkml.sepix@code.wastedcycles.net>
--- linux-2.6.32-rc6-wio/include/scsi/scsi.h    2009-11-03 19:37:49.000000000 +0000
+++ linux-2.6.32-rc6-wii/include/scsi/scsi.h    2009-11-10 22:54:01.000000000 +0000
@@ -284,8 +284,10 @@
        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 /* __KERNEL__ */
 
 /*
  * standard mode-select header prepended to all mode-select commands

Re: [PATCH] SCSI: userspace cannot use scsi_device_type

[James Bottomley]

On Wed, 2009-11-11 at 18:16 +0000, Jeff Smith wrote:
> The following patch fixes the 'make headers_check' warning:
>     include/scsi/scsi.h:288: userspace cannot call function or variable defined in the kernel
> It is similar to a patch from Jaswinder Singh Rajput back in July, which did not initially compile.
> 
> I have compiled this patch, and as expected it generates the same kernel code with and without,
> modulo the confusion caused by printk pollution that uses __DATE__ and __TIME__ and compressions
> thereof. This indicates that the patch is harmless to apply from the kernel's POV. A search on google
> and google/codesearch indicated that there is no obvious userland use of the scsi_device_type
> identifier in a way that depends on the scsi.h code.
> 
> A similar patch for the scsi_command_size code should be feasible, but a code search reveals some 
> explicit use of the include file for the command_size definitions, in OpenAFS in particular,
> so I figure that should be submitted as a separate patch (or more likely, RFC) after I have 
> worked through the usages I can see (none of which, in theory, should be valid anyway) and 
> after any comment on this patch.

Actually, there are several other problems like this that need
fixing ... and for which we have patches submitted.  The debating point
is whether we actually want to clean scsi.h and the allied headers up
enough so we can ask Ulrich actually to use them for glibc ... and where
the resulting headers should be placed.  So far we have no consensus on
this.

Personally, I think a line by line comparison of the scsi.h in Ulrich's
glibc tree and ours making it identical and shoving all the non kernel
stuff into other headers might be the way to go .. but others have
disagreed in the past.

James

Re: [PATCH] SCSI: userspace cannot use scsi_device_type

[Jeff Smith]

James Bottomley wrote:
> On Wed, 2009-11-11 at 18:16 +0000, Jeff Smith wrote:
>> The following patch fixes the 'make headers_check' warning:
>>     include/scsi/scsi.h:288: userspace cannot call function or variable defined in the kernel
>> It is similar to a patch from Jaswinder Singh Rajput back in July, which did not initially compile.
[..snip..]
>> A similar patch for the scsi_command_size code should be feasible, but a code search reveals some 
[..snip..]
 
> Actually, there are several other problems like this that need
> fixing ... and for which we have patches submitted.  

Thanks for the hint -- I've found some of them now! Sorry! (I am not
on linux-scsi, so I have a bit of catching-up to do.)

> The debating point
> is whether we actually want to clean scsi.h and the allied headers up
> enough so we can ask Ulrich actually to use them for glibc ... and where
> the resulting headers should be placed.  So far we have no consensus on
> this.

If there is no agreement on asking Ulrich or on ultimate filestore location, the
question is whether meanwhile it's worth deploying the minimal cleaning necessary
to avoid warnings and other known small difficulties (as mentioned 
in eg. Michael S. Tsirkin's patchset). I assume you think that the debate 
will resolve itself in due course, so a minor stall now is preferable?
 
> Personally, I think a line by line comparison of the scsi.h in Ulrich's
> glibc tree and ours making it identical and shoving all the non kernel
> stuff into other headers might be the way to go .. but others have
> disagreed in the past.

Personally I agree with your approach, but I wouldn't want to do actual
work on it if it's unlikely to get deployed.

Jeff

> James
> 
>