Re: [PATCH 2.6.10-rc1 4/4] driver-model: attach/detach sysfs node implemented

[Tejun Heo]

 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/