> Yes, Pat and I have talked a lot about the need for a driver "state". I
> think the current goal was to see how far we can get without needing it.
> I was certainly cursing the lack of it today when trying to debug this
> problem, but in the end, having it would have only masked over the
> real problem that was there.
It'd actually be a "device state", not a "driver state" ...
And I suspect that the specific usbfs issue got fixed by that patch
to make its disconnect() method actually do its job, earlier this
year. If there's an open issue, I'd likely characterize it as needing
to trust device drivers to disconnect() correctly ... without having
good ways to verify (later on) they really did so. Unfortunately
that's an area where we know drivers like to make mistakes.
>>Without having a way to answer that question, today's un-helpful
>>"driver is in active use" refcount would encourage rmmodding drivers
>>that users will expect to still be available. Plug in two devices,
>>look at one, decide to use the other, unplug the first ... and just
>>because you hadn't yet opened the second device, its driver module
>>vanishes. As you start to use it ... huge frustration quotient! :)
>
>
> Well, that's a driver unload issue, which I think everyone agrees on the
> fact that it's not ok to do automatic driver unload when a device is
> removed, because of this very problem.
I think it _could_ be fine to do such rmmods, if all the module
remove races were removed ... and (for this issue) if the primitve
were actually "remove if the driver is not (a) in active use, or
(b) bound to any device". Today we have races and (a) ... but it's
the lack of (b) that prevents hotplug from even trying to rmmod,
on the optimistic assumption there are no races.
- Dave
On Thu, Sep 26, 2002 at 09:14:48AM -0700, David Brownell wrote:
>
> >Yes, Pat and I have talked a lot about the need for a driver "state". I
> >think the current goal was to see how far we can get without needing it.
> >I was certainly cursing the lack of it today when trying to debug this
> >problem, but in the end, having it would have only masked over the
> >real problem that was there.
>
> It'd actually be a "device state", not a "driver state" ...
Doh, yes, that's what I meant, sorry.
> >Well, that's a driver unload issue, which I think everyone agrees on the
> >fact that it's not ok to do automatic driver unload when a device is
> >removed, because of this very problem.
>
> I think it _could_ be fine to do such rmmods, if all the module
> remove races were removed ... and (for this issue) if the primitve
> were actually "remove if the driver is not (a) in active use, or
> (b) bound to any device". Today we have races and (a) ... but it's
> the lack of (b) that prevents hotplug from even trying to rmmod,
> on the optimistic assumption there are no races.
But how do we accomplish (b) for devices that we can't remove from the
system? Like 99.9% of the pci systems?
I agree it would be "nice", but probably never realistic :)
thanks,
greg k-h
On Thu, 26 Sep 2002, Greg KH wrote:
> On Thu, Sep 26, 2002 at 09:14:48AM -0700, David Brownell wrote:
> > I think it _could_ be fine to do such rmmods, if all the module
> > remove races were removed ... and (for this issue) if the primitve
> > were actually "remove if the driver is not (a) in active use, or
> > (b) bound to any device". Today we have races and (a) ... but it's
> > the lack of (b) that prevents hotplug from even trying to rmmod,
> > on the optimistic assumption there are no races.
>
> But how do we accomplish (b) for devices that we can't remove from the
> system? Like 99.9% of the pci systems?
>
> I agree it would be "nice", but probably never realistic :)
This raises a generally interesting question: When should a driver module
be loaded?
Should it be there all the time? -- usually not. Or only when the device
is in active use? Also at detection (hotplug) and removal time? As long
as the device is installed? What if the device is built into the system
and can never be removed? What if the device is not subject to
hotplugging itself but is required in order to operate another device that
can be hotplugged (e.g., a USB host controller driver)?
I think it's clear that the answer must depend on the particular driver,
and that no single scheme involving usage counts (or the equivalent) can
suffice for every situation.
Is there a way to let the kernel provide a variety of mechanisms and let
the device driver (or even the user) select which one gets used?
Alan Stern
> This raises a generally interesting question: When should a driver
> module be loaded?
It is an interesting question, but it is not a kernel problem :-)
[..]
> I think it's clear that the answer must depend on the particular driver,
> and that no single scheme involving usage counts (or the equivalent) can
> suffice for every situation.
>
> Is there a way to let the kernel provide a variety of mechanisms and let
> the device driver (or even the user) select which one gets used?
That is more or less what is in place. There's a kernel aspect to the problem,
because the kernel needs to implement an unload if nothing is bound to method,
as user space cannot do that without a race.
Regards
Oliver