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.
signature.asc
Description: This is a digitally signed message part
