Messages in this thread | | | Date | Fri, 5 Nov 2004 13:45:37 +0900 | From | Tejun Heo <> | Subject | Re: [PATCH 2.6.10-rc1 4/4] driver-model: attach/detach sysfs node implemented |
| |
Hello Dmitry. Hello Greg.
On Thu, Nov 04, 2004 at 11:06:19AM -0800, Dmitry Torokhov wrote: > What about connecting? I am pretty ignorant of USB inner workings > but when I took a glance there seems to be a lot of preparations > before device is ready to be probed...
IMHO, it would be better to coerce whatever bus to follow common driver-model synchronization/attach/detach rules and be able to do straight-forward implementation of features in the core driver-model. If the current driver-model isn't enough, the core code should be expanded rather than doing bus-specific dances in individual buses. But I don't really know about any bus other than PCI, so maybe I'm being too naive.
> > problems (as long as it's not the hub driver from a hub device, we need > > to never be able to disconnect those.) > > Never say never ;) That was the first thing I did after playing with > PCI devices when I tried doing what Tejun did. > > If kernel advertises an userspace interface it will be used. I can see > myself wanting to disconnect my hub and all its devices so my wireless > explorer does not use batteries and I do not want to figure out what > port it is connected to... Someone else will find another reason, > I don't know. > > I also think that even PCI should kill children devices behind a bridge > if bridge driver is disconnected to manage resources in more strict way. > But I think that would require notion of generic/specialized driver and > require automatic rebinding of specialized driver over generic one so > every PCI device has a driver attached to it.
I think above can be cleanly solved by enforcing that no device can be attached to a driver unless all its ancestors are attached to a driver. The check can be made easiliy inside the driver-model, and, if needed, making dummy drivers for internal node devices which orignally didn't need one shouldn't be difficult. We can just return -EBUSY for any attempts to detach an internal device which has driver-attached children. This way, recursing and all other chores can be dumped to user-space where they belong.
And regarding the duplicate works, my work on manual-attach was primarily to show how dynamic device-driver binding can work with devparam; also, Dmitry seems to understand the problem better than me. So, I think I should back off on manualattach. Dmitry, what do you think about integrating devparam with your work?
Thanks.
-- tejun
- 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/
| |