Re: [RFC] [PATCH] driver core: allow userspace to unbind drivers from devices.

Dmitry Torokhov
2004-11-16T21:17:37Z

On Tue, 16 Nov 2004 02:04:13 -0500, Adam Belay <ambx1@neo.rr.com> wrote:
>
> "*stop"
> - safely stop the upper class layer
> - free resources, and reset device specific data
>
> And we're ready for the next step. (which may even include another *start)
>
> This would easily allow for things like "reconnect", which would simply be a
> "*stop" follow by a "*start".
>
> Comments?
>

Sounds interesting, although I do not think that freeing resources should be
done at stop time, it is task for remove() IMHO. Do you have an idea how
setting up process (between probe and start) will work? Will start called
automatically or by request from userspace?

>
> > My bind mode patch is somewhat independent of "drvctl" as it just adds a new
> > attribute - "bind_mode" to all devices and drivers. It can be either "auto"
> > or "manual" and device/drivers that are set as manual mode will be ignored
> > by driver core and will only be bound when user explicitely asks to do that.
> > This is useful when you want "penalize" one driver over another, like
> > psmouse/serio_raw.
>
> That's actually a really interesting idea. In some cases we may not want the
> kernel automatically binding drivers. A question would be should this feature
> be disabled on a per device basis or globally? If it's globally then should
> it occur after init is done. And if that's the case, couldn't we free the
> device ID tables and handle everything from userspace. I'm sure there are
> some problems with this but I figured I'd mention it as well.
>

Well, it sure needs to be available on per-device/per-driver basis as while
I am generally enjoying automatic binding without userspace involvement.
For example I sometimes want to be able to disable my touchpad and not
let it spring back to life (normally serio core will try to find
proper driver for
an unbound port whenever there is a data coming from it).

Whether it should also be controlled on per bus/per system basis is
another question. I am not quite ready to drop all device tables and rely
solely on userspace handling, altthough if all tables are marked as __init
and and the end of the boot process we walk all buses and set their
->match() methods to NULL we effectively switch to manual binding
mode and can discard ID tables.

--
Dmitry