Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752014Ab0LOQn5 (ORCPT ); Wed, 15 Dec 2010 11:43:57 -0500 Received: from cantor.suse.de ([195.135.220.2]:44703 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751608Ab0LOQnz (ORCPT ); Wed, 15 Dec 2010 11:43:55 -0500 Date: Wed, 15 Dec 2010 08:23:16 -0800 From: Greg KH To: Cornelia Huck Cc: Sebastian Ott , Kay Sievers , linux-kernel@vger.kernel.org Subject: Re: [RFC] bind/unbind uevent Message-ID: <20101215162316.GA31141@suse.de> References: <20101207183305.GA21802@suse.de> <20101208160255.GB10313@suse.de> <20101213193617.GA18262@suse.de> <20101214192952.GA9106@suse.de> <20101215142113.7d416d78@gondolin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101215142113.7d416d78@gondolin> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2397 Lines: 57 On Wed, Dec 15, 2010 at 02:21:13PM +0100, Cornelia Huck wrote: > On Tue, 14 Dec 2010 11:29:52 -0800, > Greg KH 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 -- 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/