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