I don't think moving to a generic usb driver is going to help.. the problem
there is that userspace would need to change what that driver can accept
and then re-issue a probe, _without_ unloading and reloading the module.
We could do that, but we don't currently have code there. And then we
could wind up racing with an already running probe sequence anyway. So
we're back to the same problem.
I think we need some sort of mutual exclusion between usbdevfs and probing.
In other words, if usbdevfs tries to do a claim_interface(), it will either
block while the probe sequence is running, or simply fail with an error
code.
Of course, this also raises the question of, what _else_ did we miss with
usbdevfs -- there are a lot of special cases with that.
Matt
On Sat, Oct 20, 2001 at 07:34:31PM -0400, Johannes Erdfelt wrote:
> On Sun, Oct 21, 2001, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > > f) no problem at all. this is as designed
> > >
> > > It's probably a design flaw.
> >
> > Maybe we should abandon the idea of using a filesystem for this and have a
> > driver for an "usb generic" device ? The amount of special casing would be
> > reduced.
>
> Not necessarily. Using a custom filesystem, versus a device node still
> ends up using an ioctl(), read(), or the like.
>
> You still have the same issues.
>
> Thomas had some good reasons at the time for using a filesystem. I think
> I may still have the conversation somewhere. It mostly applied to
> locking and race conditions being easier to control with a filesystem.
>
> JE
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
C: They kicked your ass, didn't they?
S: They were cheating!
-- The Chief and Stef
User Friendly, 11/19/1997
PGP signature
