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

[Greg KH]

On Tue, Nov 16, 2004 at 01:13:15AM -0500, Adam Belay wrote:
> 
> I'm not sure what your bind_mode patch includes, but I would like to start a
> general discussion on the bind/unbind issue.
> 
> I appreciate the effort, and I agree that this feature is important.  However,
> I would like to discuss a few issues.
> 
> 1.) I don't think we should merge a patch that supports driver "unbind"
> without also supporting driver "bind".
> 
> They're really very interelated, and we don't want to break userspace by
> changing everything around when we discover a cleaner solution.

How would we break userspace, when you can't do either thing today?
Just by adding one new feature, doesn't break anything :)

Anyway, I agree, but the core needs to have it's locking reworked in
order for this to work properly.  I'm working on this now.

> 2.) I don't like having an "unbind" file.

Why?

> This implies that we will have at least three seperate files controlling
> driver binding when we really need only one or two at the most.  Consider
> "bind", "unbind", and the link to the driver that is bound.

No.  Consider the fact that the "unbind" file will not be present if the
device is not bound to anything.  Once it is bound, the unbind file will
be created, and the symlink will be created.  The symlink matches other
parts of sysfs.  By trying to put the name of the driver in a file, that
makes userspace work a lot harder to try to figure out exactly what
driver is bound (consider the fact that I can have both a pci and a usb
driver with the same name in sysfs, and that's legal.)

So, when a device is not bound to a driver, there will be no symlink, or
a "unbind" file, only a "bind" file.  Really there is only 1 "control"
type file present at any single point in time.

Sound good?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/