scsi: export and clean up headers
v2 cover scsi: export and clean up headers
This implements a minor cleanup of exported scsi headers, and adds export of headers that are de-facto used by userspace. The patches are on top of 2.6.32-rc1.
Can these be queued for 2.6.32?
Thanks.
Michael S. Tsirkin (4):
scsi: consistent use of __u8 in scsi/scsi.h
scsi: make scsi/scsi.h headers_check clean
scsi: export scsi_ioctl.h and sg.h headers
scsi: export scsi_tgt_if.h
include/scsi/Kbuild | 3 +++ include/scsi/scsi.h | 12 ++++++++---- 2 files changed, 11 insertions(+), 4 deletions(-)
Quoted 6 lines · On Tue, 29 Sep 2009 12:33:53 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
This implements a minor cleanup of exported scsi headers, and adds export of headers that are de-facto used by userspace. The patches are on top of 2.6.32-rc1.
Can these be queued for 2.6.32?
Thanks.
one of the problems I've found is that glibc has its own copy of scsi headers, causing interesting conflicts. Do you know for sure that with these cleanups we can retire the glibc headers? (that would be very welcome)
If not, do you know what it would take to get to that point?
Signature · 3 lines
Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
Quoted 10 lines · Arjan van de Ven
Quoted 6 lines · On Tue, 29 Sep 2009 12:33:53 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
This implements a minor cleanup of exported scsi headers, and adds export of headers that are de-facto used by userspace. The patches are on top of 2.6.32-rc1.
Can these be queued for 2.6.32?
Thanks.
Quoted 4 lines
one of the problems I've found is that glibc has its own copy of scsi headers, causing interesting conflicts. Do you know for sure that with these cleanups we can retire the glibc headers? (that would be very welcome)
I don't see why not.
The only differences with glibc headers that I can see:
- glic adds #include <features.h> on top of each header
- glibc has old SCSI_IOCTL_TAGGED_ENABLE/SCSI_IOCTL_TAGGED_DISABLE
Quoted 1 line
If not, do you know what it would take to get to that point?
Probably just talk to Ulrich or other glibc developers. If there's some symbol that's missing, we can always add it.
Quoted 4 lines
Signature · 3 lines
Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
Quoted 5 lines · Michael S. Tsirkin
This implements a minor cleanup of exported scsi headers, and adds export of headers that are de-facto used by userspace. The patches are on top of 2.6.32-rc1.
Can these be queued for 2.6.32?
Thanks.
Before we do anything in this area we need to find an agreement who owns /usr/include/scsi/ . Right now that's glibc, and if we want to change it to the kernel headers we need to find a transition agreement with the glibc maintainer (aka mostly Uli).
And even then it's quite questionable if the kernel should provide scsi.h as it's mostly protocol defintions, not actually a kernel interface.
Quoted 9 lines · Christoph Hellwig
Quoted 5 lines · Michael S. Tsirkin
This implements a minor cleanup of exported scsi headers, and adds export of headers that are de-facto used by userspace. The patches are on top of 2.6.32-rc1.
Can these be queued for 2.6.32?
Thanks.Before we do anything in this area we need to find an agreement who owns
/usr/include/scsi/.
Let's cleanup headers that we already export (that's patches 1/2 in the series). I don't see a reason to delay that, do you?
Quoted 3 lines
Right now that's glibc, and if we want to
change it to the kernel headers we need to find a transition agreement with the glibc maintainer (aka mostly Uli).
Who cares? If glibc wants to carry its own headers, let it. It will likely switch if what kernel provides is sane (it is currently not). So let's start with cleaning up what we already have. If glibc decides not to use it, no harm's done.
Quoted 3 lines
And even then it's quite questionable if the kernel should provide
scsi.has it's mostly protocol defintions, not actually a kernel interface.
It has a ton of ioctl definitions there.
Signature · 1 line
MST
Quoted 11 lines · Christoph Hellwig
Quoted 5 lines · Michael S. Tsirkin
This implements a minor cleanup of exported scsi headers, and adds export of headers that are de-facto used by userspace. The patches are on top of 2.6.32-rc1.
Can these be queued for 2.6.32?
Thanks.Before we do anything in this area we need to find an agreement who owns
/usr/include/scsi/. Right now that's glibc, and if we want to change it to the kernel headers we need to find a transition agreement with the glibc maintainer (aka mostly Uli).
The scsi headers are exported. So it does not matter if glibc or any other libc for that amtter uses the headers or not.
Exported headers has some rules to follow and scsi are no exception here.
Now if we get the scsi headers in good shape then and only then we can go to glibc people and tell them that we have a better set of scsi headers than they have.
Postponing updates to the exported scsi headers just beacause we do not have any users of them at the moment is the wrong thing to do. We should rather use the opportunity to streamline the exported headers so we have a superior set of headers to offer.
Sam
Quoted 21 lines · Sam Ravnborg
Quoted 11 lines · Christoph Hellwig
Quoted 5 lines · Michael S. Tsirkin
This implements a minor cleanup of exported scsi headers, and adds export of headers that are de-facto used by userspace. The patches are on top of 2.6.32-rc1.
Can these be queued for 2.6.32?
Thanks.Before we do anything in this area we need to find an agreement who owns
/usr/include/scsi/. Right now that's glibc, and if we want to change it to the kernel headers we need to find a transition agreement with the glibc maintainer (aka mostly Uli).The scsi headers are exported. So it does not matter if glibc or any other libc for that amtter uses the headers or not.
Exported headers has some rules to follow and scsi are no exception here.Now if we get the scsi headers in good shape then and only then we can go to glibc people and tell them that we have a better set of scsi headers than they have.
Quoted 6 lines
Postponing updates to the exported scsi headers just beacause we do not have any users of them at the moment is the wrong thing to do. We should rather use the opportunity to streamline the exported headers so we have a superior set of headers to offer.
Sam
Ulrich, does it create problems for you if we fix kernel headers for scsi? Does it make your life easier?
Signature · 1 line
MST
Quoted 17 lines · Sam Ravnborg
Quoted 11 lines · Christoph Hellwig
Quoted 5 lines · Michael S. Tsirkin
This implements a minor cleanup of exported scsi headers, and adds export of headers that are de-facto used by userspace. The patches are on top of 2.6.32-rc1.
Can these be queued for 2.6.32?
Thanks.Before we do anything in this area we need to find an agreement who owns
/usr/include/scsi/. Right now that's glibc, and if we want to change it to the kernel headers we need to find a transition agreement with the glibc maintainer (aka mostly Uli).The scsi headers are exported. So it does not matter if glibc or any other libc for that amtter uses the headers or not.
Exported headers has some rules to follow and scsi are no exception here.
Quoted 8 lines
Now if we get the scsi headers in good shape then and only then we can go to glibc people and tell them that we have a better set of scsi headers than they have.
Postponing updates to the exported scsi headers just beacause we do not have any users of them at the moment is the wrong thing to do. We should rather use the opportunity to streamline the exported headers so we have a superior set of headers to offer.
can we get these fixes merged ? i dont see them in 2.6.33-rc1 ... -mike
--
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