Re: [PATCH] SCSI: userspace cannot use scsi_command_size_tbl, COMMAND_SIZE and scsi_device_type

[Boaz Harrosh <bharrosh@panasas.com>]

On 06/28/2009 04:52 PM, James Bottomley wrote:
> On Sun, 2009-06-28 at 00:10 +0530, Jaswinder Singh Rajput wrote:
>> On Sat, 2009-06-27 at 12:28 -0600, Matthew Wilcox wrote:
>>> On Sat, Jun 27, 2009 at 11:26:28PM +0530, Jaswinder Singh Rajput wrote:
>>>>> On Sat, 2009-06-27 at 22:35 +0530, Jaswinder Singh Rajput wrote:
>>>>>> userspace cannot use scsi_command_size_tbl, COMMAND_SIZE
>>>>>> and scsi_device_type defined in kernel
>>> When did we start exporting include/scsi to userspace?  I thought glibc
>>> had its own separate definitions.
>>>
>> commit 9e4f5e29610162fd426366f3b29e3cc6e575b858
>> Author: James Smart <James.Smart@Emulex.Com>
>> Date:   Thu Mar 26 13:33:19 2009 -0400
>>
>>     [SCSI] FC Pass Thru support
> 
> That's what you get from a simplistic view.
> 
> If you look at the full history, scsi.h and sg.h were exported in 2006
> by the initial commit by David Woodhouse
> 
> commit 8555255f0b426858d8648c6206b70eb906cf4ec7
> Author: David Woodhouse <dwmw2@infradead.org>
> Date:   Sun Jun 18 12:14:01 2006 +0100
> 
>     Add generic Kbuild files for 'make headers_install'
> 
> They were unexported again a year later, apparently on grounds of
> clashing with /usr/include/scsi from glibc:
> 
> commit e629a7ddc0188e1bb9e956e698a9bd00c19c9854
> Author: Olaf Hering <olh@suse.de>
> Date:   Tue Oct 16 23:27:01 2007 -0700
> 
>     do not export /usr/include/scsi in make headers_install
> 
> So perhaps the meta question is how are we supposed to resolve this?
> Glibc ceded it's copy of /usr/include/linux to the kernel headers
> package, so it looks to be an oversight that it still
> retains /usr/include/scsi (there's nothing extra in there in glibc
> beyond what SCSI exports).
> 
> James
> 
> 

Right! so a good strategy might be to first fix up the header for proper
user-mode consumption. And then just let glibc eventually drop their scsi.h
header once enough complains register.

Though out of courtesy someone might send a patch to the glibc maintainers to
remove that header. Andrew do you have any passed experience with this project?

I agree that Kernel should get back control of this header.

Boaz