All of lore.kernel.org
 help / color / mirror / Atom feed
* old linux scsi headers
@ 2015-01-09 17:38 Andy Grover
  2015-01-10 10:10 ` Christoph Hellwig
  0 siblings, 1 reply; 3+ messages in thread
From: Andy Grover @ 2015-01-09 17:38 UTC (permalink / raw)
  To: libc-alpha; +Cc: linux-scsi, James Bottomley, Christoph Hellwig

Hello glibc people,

This concerns sysdeps/unix/sysv/linux/scsi/{scsi, scsi_ioctl, sg}.h

They define common SCSI values, as well as Linux's SCSI-related ioctls.

Apparently they were copied from the Linux kernel tree back in 1999, so 
they're pretty stale.

I'm wondering if I should submit a patch to update these to what's 
current from the Linux tree, or if maybe it wouldn't be better to have 
users just directly get these as "uapi" headers from the Linux kernel 
source directly?

The latter method has issues with being a breaking change for code that 
relies on what's in glibc now, which may or may not be something we can 
ease, but would ensure the headers would not become stale again in the 
future.

What do you think about the best way to proceed?

Thanks -- Regards -- Andy

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: old linux scsi headers
  2015-01-09 17:38 old linux scsi headers Andy Grover
@ 2015-01-10 10:10 ` Christoph Hellwig
  2015-01-27 19:42   ` Andy Grover
  0 siblings, 1 reply; 3+ messages in thread
From: Christoph Hellwig @ 2015-01-10 10:10 UTC (permalink / raw)
  To: Andy Grover; +Cc: libc-alpha, linux-scsi, James Bottomley, Christoph Hellwig

On Fri, Jan 09, 2015 at 09:38:50AM -0800, Andy Grover wrote:
> Hello glibc people,
>
> This concerns sysdeps/unix/sysv/linux/scsi/{scsi, scsi_ioctl, sg}.h
>
> They define common SCSI values, as well as Linux's SCSI-related ioctls.
>
> Apparently they were copied from the Linux kernel tree back in 1999, so 
> they're pretty stale.
>
> I'm wondering if I should submit a patch to update these to what's current 
> from the Linux tree, or if maybe it wouldn't be better to have users just 
> directly get these as "uapi" headers from the Linux kernel source directly?
>
> The latter method has issues with being a breaking change for code that 
> relies on what's in glibc now, which may or may not be something we can 
> ease, but would ensure the headers would not become stale again in the 
> future.
>
> What do you think about the best way to proceed?

FYI, I'd like to repeat my propsal from the scsi list here, and a
few alternatives:

(1) separate namespaces (my proposal):

 - we add uapi linux/scsi_ioctl.h and linux/sg.h files that just
   add the ioctl defintions and data structures required for them.
 - because they are linux/ instead of scsi/ are not required to keep
   things like the old opcode or SCSI-2 defintions, which glibc
   can keep in the scsi/* wrappers, and hopefully slowly deprecate
   over the long run

(2) just export what we have in the kernel now (Andys patch):

 - add uapi scsi/scsi.h and scsi/scsi_ioctl.h (and scsi/sg.h for v2),
   exporting what we have in them right now, which might be a little
   different from glibc
 - remove glibcs scsi/*.h

(2a)

 - like 2, but only export the ioctls APIs, the other constants
   will go away at this point

(2b)

 - like 2a, but also add defines compatible to glibc under
   #ifndef __KERNEL__ to the uapi headers.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: old linux scsi headers
  2015-01-10 10:10 ` Christoph Hellwig
@ 2015-01-27 19:42   ` Andy Grover
  0 siblings, 0 replies; 3+ messages in thread
From: Andy Grover @ 2015-01-27 19:42 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: libc-alpha, linux-scsi, James Bottomley

On 01/10/2015 02:10 AM, Christoph Hellwig wrote:
> On Fri, Jan 09, 2015 at 09:38:50AM -0800, Andy Grover wrote:
>> Hello glibc people,
>>
>> This concerns sysdeps/unix/sysv/linux/scsi/{scsi, scsi_ioctl, sg}.h
>>
>> They define common SCSI values, as well as Linux's SCSI-related ioctls.
>>
>> Apparently they were copied from the Linux kernel tree back in 1999, so
>> they're pretty stale.
>>
>> I'm wondering if I should submit a patch to update these to what's current
>> from the Linux tree, or if maybe it wouldn't be better to have users just
>> directly get these as "uapi" headers from the Linux kernel source directly?
>>
>> The latter method has issues with being a breaking change for code that
>> relies on what's in glibc now, which may or may not be something we can
>> ease, but would ensure the headers would not become stale again in the
>> future.
>>
>> What do you think about the best way to proceed?
>
> FYI, I'd like to repeat my propsal from the scsi list here, and a
> few alternatives:
>
> (1) separate namespaces (my proposal):
>
>   - we add uapi linux/scsi_ioctl.h and linux/sg.h files that just
>     add the ioctl defintions and data structures required for them.
>   - because they are linux/ instead of scsi/ are not required to keep
>     things like the old opcode or SCSI-2 defintions, which glibc
>     can keep in the scsi/* wrappers, and hopefully slowly deprecate
>     over the long run

Fine by me. This lets the kernel publish up-to-date headers, and lets 
glibc handle the old headers at its own pace.

I'll post a patch shortly.

Regards -- Andy

>
> (2) just export what we have in the kernel now (Andys patch):
>
>   - add uapi scsi/scsi.h and scsi/scsi_ioctl.h (and scsi/sg.h for v2),
>     exporting what we have in them right now, which might be a little
>     different from glibc
>   - remove glibcs scsi/*.h
>
> (2a)
>
>   - like 2, but only export the ioctls APIs, the other constants
>     will go away at this point
>
> (2b)
>
>   - like 2a, but also add defines compatible to glibc under
>     #ifndef __KERNEL__ to the uapi headers.
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-01-27 19:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-09 17:38 old linux scsi headers Andy Grover
2015-01-10 10:10 ` Christoph Hellwig
2015-01-27 19:42   ` Andy Grover

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.