Package: linux-2.6
Severity: wishlist

Please consider including the USB/IP drivers from the
staging directory:

CONFIG_USB_IP_COMMON=m
CONFIG_USB_IP_VHCI_HCD=m
CONFIG_USB_IP_HOST=m

As I understand, the drivers remain in staging not so much
because of quality issues but due to discussions about the
userspace API, which may still change.

The only users of the API which exist today are the usbip
userspace tools through libusbip0. It should be possible to
adapt those if/when the API changes.

If these modules were provided in linux-2.6, we could drop
the usbip-source module package.

Max



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, 2010-02-08 at 18:15 +0100, Max Vozeler wrote:
> Package: linux-2.6
> Severity: wishlist
>
> Please consider including the USB/IP drivers from the
> staging directory:
>
> CONFIG_USB_IP_COMMON=m
> CONFIG_USB_IP_VHCI_HCD=m
> CONFIG_USB_IP_HOST=m
>
> As I understand, the drivers remain in staging not so much
> because of quality issues but due to discussions about the
> userspace API, which may still change.

The implementation is questionable too.

> The only users of the API which exist today are the usbip
> userspace tools through libusbip0. It should be possible to
> adapt those if/when the API changes.
>
> If these modules were provided in linux-2.6, we could drop
> the usbip-source module package.

Given that this is not needed for hardware support, I would like to see
a good reason for including it.

Ben.

--
Ben Hutchings
friends: People who know you well, but like you anyway.

Hi Ben,

On Tue, Feb 09, 2010 at 03:21:15AM +0000, Ben Hutchings wrote:
> On Mon, 2010-02-08 at 18:15 +0100, Max Vozeler wrote:
> > Please consider including the USB/IP drivers from the
> > staging directory:
> >
> > CONFIG_USB_IP_COMMON=m
> > CONFIG_USB_IP_VHCI_HCD=m
> > CONFIG_USB_IP_HOST=m
> >
> > As I understand, the drivers remain in staging not so much
> > because of quality issues but due to discussions about the
> > userspace API, which may still change.
>
> The implementation is questionable too.

Could you point me to related discussions or things you
noticed which look odd?

> > The only users of the API which exist today are the usbip
> > userspace tools through libusbip0. It should be possible to
> > adapt those if/when the API changes.
> >
> > If these modules were provided in linux-2.6, we could drop
> > the usbip-source module package.
>
> Given that this is not needed for hardware support, I would like to see
> a good reason for including it.

OK. Let me try to give a balanced view:

The drivers provide a new and experimental feature,
which has gotten to the point of being usable in some
limited but practical scenarios.

One I've been working on is remote access to hardware
security modules from within virtual machines.

There are still limitations that make it unsuitable
for less specialized setups. Device reconnects are not
handeled transparently yet, for example.

Other limitations lie in the usbip userspace tools, the
most important probably being the lack of authorization
for access to the usbip daemon.

Despite these limitations, there are people wanting to
use usbip in setups where the limitations don't matter
or can be worked around (e.g. using IPSec transport).

So that's why I think is is useful to have.

Now about whether to enable it in linux-2.6 or ship it
as a separate module source package (usbip-source).

The drivers have so far been developed in two places,
one being the usbip svn repo at sourceforce, the other
the mainline staging tree.

This has led to diverging and usbip upstream is now
starting to move the driver development away from the
separate svn repo towards doing it in the staging tree.

So in the future the usbip-source module package will
be mostly a copy of the drivers from staging.

Including it in linux-2.6 would likely allow us to drop
the separate usbip-source package, make it easier for
users to get the modules and keep them updated.

I don't think these are really strong reasons for
including it in linux-2.6 vs. having the module package
considering that it is experimental and niche enough
to only be interesting to relatively few people.

On the other hand, since staging is going to be where
the development happens, it seems that it is also the
best place to build the modules from.

Hope that gives you a basis for deciding about whether
to include it or keep it separate.

Max



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, 2010-02-09 at 14:21 +0100, Max Vozeler wrote:
> Hi Ben,
>
> On Tue, Feb 09, 2010 at 03:21:15AM +0000, Ben Hutchings wrote:
> > On Mon, 2010-02-08 at 18:15 +0100, Max Vozeler wrote:
> > > Please consider including the USB/IP drivers from the
> > > staging directory:
> > >
> > > CONFIG_USB_IP_COMMON=m
> > > CONFIG_USB_IP_VHCI_HCD=m
> > > CONFIG_USB_IP_HOST=m
> > >
> > > As I understand, the drivers remain in staging not so much
> > > because of quality issues but due to discussions about the
> > > userspace API, which may still change.
> >
> > The implementation is questionable too.
>
> Could you point me to related discussions or things you
> noticed which look odd?

Comments like:

/*
* When removing an exported device, kernel panic sometimes occurred
* and then EIP was sk_wait_data of stub_rx thread. Is this because
* sk_wait_data returned though stub_rx thread was already finished by
* step 1?
*/

> > > The only users of the API which exist today are the usbip
> > > userspace tools through libusbip0. It should be possible to
> > > adapt those if/when the API changes.
> > >
> > > If these modules were provided in linux-2.6, we could drop
> > > the usbip-source module package.
> >
> > Given that this is not needed for hardware support, I would like to see
> > a good reason for including it.
>
> OK. Let me try to give a balanced view:
>
> The drivers provide a new and experimental feature,
> which has gotten to the point of being usable in some
> limited but practical scenarios.
>
> One I've been working on is remote access to hardware
> security modules from within virtual machines.

What could possibly go wrong?!

> There are still limitations that make it unsuitable
> for less specialized setups. Device reconnects are not
> handeled transparently yet, for example.
>
> Other limitations lie in the usbip userspace tools, the
> most important probably being the lack of authorization
> for access to the usbip daemon.

Apparently there are some serious problems with the protocol too.

[....]
> So in the future the usbip-source module package will
> be mostly a copy of the drivers from staging.
>
> Including it in linux-2.6 would likely allow us to drop
> the separate usbip-source package, make it easier for
> users to get the modules and keep them updated.
>
> I don't think these are really strong reasons for
> including it in linux-2.6 vs. having the module package
> considering that it is experimental and niche enough
> to only be interesting to relatively few people.
>
> On the other hand, since staging is going to be where
> the development happens, it seems that it is also the
> best place to build the modules from.
>
> Hope that gives you a basis for deciding about whether
> to include it or keep it separate.

OK, I suppose 'staging' is probably a big enough warning label. I think
we can enable this for x86. Please look for out bug reports.

Ben.

--
Ben Hutchings
73.46% of all statistics are made up.

Hi Ben,

On Fri, Feb 12, 2010 at 02:52:58AM +0000, Ben Hutchings wrote:
> On Tue, 2010-02-09 at 14:21 +0100, Max Vozeler wrote:
> > On Tue, Feb 09, 2010 at 03:21:15AM +0000, Ben Hutchings wrote:
> > > The implementation is questionable too.
> >
> > Could you point me to related discussions or things you
> > noticed which look odd?
>
> Comments like:
>
> /*
> * When removing an exported device, kernel panic sometimes occurred
> * and then EIP was sk_wait_data of stub_rx thread. Is this because
> * sk_wait_data returned though stub_rx thread was already finished by
> * step 1?
> */

Uh. I see what you mean.

This particular comment might be outdated. At least I
cannot come up with a way the rx thread would fall over
if the connection is being shut down.

Noted to look more closely.

> > One I've been working on is remote access to hardware
> > security modules from within virtual machines.
>
> What could possibly go wrong?!

Heh, ;-) In terms of security, surprisingly little in fact.
Those devices treat the transport as untrusted and use a
secure channel on top of USB for authentication and privacy.

> > There are still limitations that make it unsuitable
> > for less specialized setups. Device reconnects are not
> > handeled transparently yet, for example.
> >
> > Other limitations lie in the usbip userspace tools, the
> > most important probably being the lack of authorization
> > for access to the usbip daemon.
>
> Apparently there are some serious problems with the protocol too.

The impression I got out of the discussion was that it is
too limited and underdocumented, but not fundamentally flawed.

> > Hope that gives you a basis for deciding about whether
> > to include it or keep it separate.
>
> OK, I suppose 'staging' is probably a big enough warning label. I think
> we can enable this for x86. Please look for out bug reports.

OK, will do. Please don't hesitate to point out if I miss
something in the high volume of bug reports. I'll do my best
to look into problems when I notice them.

Max



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Feb 08, 2010 at 06:15:18PM +0100, Max Vozeler wrote:
> Please consider including the USB/IP drivers from the
> staging directory:

I consider these to broken to be supported. Reasons:
- Race conditions already in the setup code.
- Buffer overflows in sysfs attribute write.

Bastian

--
If some day we are defeated, well, war has its fortunes, good and bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Bastian,

On Fri, Feb 12, 2010 at 02:50:58PM +0100, Bastian Blank wrote:
> On Mon, Feb 08, 2010 at 06:15:18PM +0100, Max Vozeler wrote:
> > Please consider including the USB/IP drivers from the
> > staging directory:
>
> I consider these to broken to be supported. Reasons:
> - Race conditions already in the setup code.
> - Buffer overflows in sysfs attribute write.

OK. Good to know. I'll try to work with upstream on the
problems you and Ben pointed out and come back to this
wishlist bug when it has better quality.

Max



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org