On Wed, Dec 15, 2010 at 02:21:13PM +0100, Cornelia Huck wrote:
quoted text
> 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?

Come on people, just look at the code!  It does exactly this today just
fine with no changes needed to the driver core.

How about I turn it around for you, please show me how the driver core
does _not_ support this today?  If you can prove that this isn't working
properly, then great, I'll gladly accept patches to resolve it.

thanks,

greg k-h
--
unsubscribe notice
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/