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(-)
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?
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Tue, Sep 29, 2009 at 12:46:20PM +0200, Arjan van de Ven wrote:
> 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)
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
> 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.
> --
> Arjan van de Ven Intel Open Source Technology Centre
> For development, discussion and tips for power savings,
> visit http://www.lesswatts.org
On Tue, Sep 29, 2009 at 12:33:53PM +0200, Michael S. Tsirkin 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.
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.
On Tue, Sep 29, 2009 at 08:43:47AM -0400, Christoph Hellwig wrote:
> On Tue, Sep 29, 2009 at 12:33:53PM +0200, Michael S. Tsirkin 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.
>
> 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?
> 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.
> 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.
It has a ton of ioctl definitions there.
--
MST
On Tue, Sep 29, 2009 at 08:43:47AM -0400, Christoph Hellwig wrote:
> On Tue, Sep 29, 2009 at 12:33:53PM +0200, Michael S. Tsirkin 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.
>
> 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
On Wed, Sep 30, 2009 at 09:15:55AM +0200, Sam Ravnborg wrote:
> On Tue, Sep 29, 2009 at 08:43:47AM -0400, Christoph Hellwig wrote:
> > On Tue, Sep 29, 2009 at 12:33:53PM +0200, Michael S. Tsirkin 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.
> >
> > 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
Ulrich, does it create problems for you if we fix kernel headers for scsi?
Does it make your life easier?
--
MST
On Wed, Sep 30, 2009 at 02:15, Sam Ravnborg wrote:
> On Tue, Sep 29, 2009 at 08:43:47AM -0400, Christoph Hellwig wrote:
>> On Tue, Sep 29, 2009 at 12:33:53PM +0200, Michael S. Tsirkin 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.
>>
>> 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.
can we get these fixes merged ? i dont see them in 2.6.33-rc1 ...
-mike