Re: [RFC] Pushing device/driver binding decisions to userspace

[Ben Collins <ben.collins@ubuntu.com>]

On Sun, 2006-11-12 at 17:47 -0800, Nicholas Miell wrote:
> On Sun, 2006-11-12 at 17:24 -0800, Ben Collins wrote:
> > On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> > > On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> > > 
> > > What's wrong with making udev or whatever unbind driver A and then bind
> > > driver B if the driver bound by the kernel ends up being the wrong
> > > choice? (Besides the inelegance of the kernel choosing one and then
> > > userspace immediately choosing the other, of course.)
> > > 
> > > I'd argue that having multiple drivers for the same hardware is a bit
> > > strange to begin with, but that's another issue entirely.
> > 
> > If two drivers are loaded for the same device, there's no way for udev
> > to tell the kernel which driver to use for a device, that I know of.
> 
> /sys/bus/*/drivers/*/{bind,unbind}

"bind" does not tell the driver core to "bind this device with this
driver", it tells it to "bind this driver to whatever devices we match
that aren't already bound".

That doesn't solve my use case.

> > Also, that just sounds very horrible to do. If you have udev/dbus events
> > flying around for "device present", "device gone", "device present",
> > then it could make for a very ugly user experience (think of programs to
> > handle devices being started because of these events).
> 
> So don't fire the events until after the final binding.

It's still not a correct solution. If we want a specific driver to be
bound to a specific device, userspace shouldn't have to jump through
hoops to do it. It should be simple and clean.

The suggestions you are giving require userspace to work around a
deficiency in the kernel, by guessing the ordering requirements to
satisfy what the user wants. In cases of hotplugging, it is also
sometimes impossible to satisfy these requirements using the current
scheme.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/