SCSI: userspace cannot use scsi_device_type

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

@@ -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

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

[..snip..]

[..snip..]

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.)

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 agree with your approach, but I wouldn't want to do actual work on it if it's unlikely to get deployed.

Jeff