Messages in this thread | | | Date | Wed, 15 Dec 2010 14:21:13 +0100 | From | Cornelia Huck <> | Subject | Re: [RFC] bind/unbind uevent |
| |
On Tue, 14 Dec 2010 11:29:52 -0800, Greg KH <gregkh@suse.de> wrote:
> On Tue, Dec 14, 2010 at 07:26:40PM +0100, Sebastian Ott wrote: > > > > On Mon, 13 Dec 2010, Greg KH wrote: > > > On Mon, Dec 13, 2010 at 08:27:45PM +0100, Sebastian Ott wrote:
> > > Don't do that, have your _driver_ register the attributes with the bus > > > it is on, then when the binding happens, the attributes will > > > automatically get created for the device before the notification is sent > > > to userspace. That is the proper proceedure here. > > > > are you suggesting that these driver specific device attributes should be > > created by the bus code which registers the device? > > Yes. > > > at this time it is not determinable which driver will bind to the device > > (and therefore which attributes to create), also driver specific data may > > not be initialized. > > {sigh} > > Please go _look_ at how the driver model handles this type of thing. It > does _exactly_ what you want, as we have been doing it for _years_ > properly. >
I don't understand how this could work. All of the attribute (groups) registered before the uevent are driver-ignorant. If the bus wants to specify the attributes, it needs to know the driver the device will bind to (regardless of whatever tables exist that show the driver <-> attribute relationship). But it cannot know the driver until after the uevent. Or else it would need to create _all_ attributes for _all_ devices (surely you didn't mean that)? And what happens with drivers that are loaded later on?
Could you please elaborate on how the attributes could be created in a compatible way with today's driver core?
Cornelia
| |