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

[Greg KH]

On Tue, Nov 16, 2004 at 02:04:13AM -0500, Adam Belay wrote:
> 
> These additional features bring up another issue that we may want the driver
> model to handle.  Basically, I think we should allow devices to be started and
> stopped.

You mean like the power management people want?  :)

> 	int	(*start)	(struct device * dev); <-----
> 	int	(*stop)		(struct device * dev); <-----

Ick, no.  Use the power interface for this.  If you aren't already on
the new linux-pm mailing list (hosted by osdl.org) you might want to be,
as people are discussing this there.

> "*probe"
> - determine if this driver is able to handle this device
> - if so create data structures that can store information about the device
> - bind the device to the driver and display additional config attributes.
> 
> At this point userspace can set up the configuration of this specific binding
> instance.  The configuration options would primarily be things that cannot be
> modified while the device is in use.  It can be loaded from a cache so that it
> is consistent between reboots, hotplugs etc.  This would sort of replace
> module parameters.

But now that module paramaters are able to be passed as command line
arguments, doesn't that solve the issue?  :)

Anyway, I think people are working on making those kind of values
persistant in a way, see the patches on lkml for something like this
(from what I can tell, I haven't really been paying attention though...)

> Now that the user has specific his or her config preferences we can go to
> "*start"
> 
> "*start"
> - parse resource information
> - fill in device/driver data structures with information
> - prepare the device to actually be used
> 
> From this point the device would be completely usable.
> 
> Then at a later time, when the device...
> - is no longer needed
> - resources need to be rebalanced
> - the user wants to remove the device in the near future
> 
> "*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?

You are forcing the user to do too much work in order for their devices
to start working :)

I understand the issue you are trying to solve, but what about something
like the "persistant device tree" issue that we've all been talking
about over the past few years?  That would let systems where we can not
probe for devices to be created all at once (like on most embedded
systems) and I think would solve your resource issues too, right?

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/