lkml.org 
[lkml]   [2010]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2010-12-15 14:23    [W:0.066 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site