linux-kernel - Re: [RFC] bind/unbind uevent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101215142113.7d416d78@gondolin>
Date:	Wed, 15 Dec 2010 14:21:13 +0100
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Greg KH <gregkh@...e.de>
Cc:	Sebastian Ott <sebott@...ux.vnet.ibm.com>,
	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] bind/unbind uevent

On Tue, 14 Dec 2010 11:29:52 -0800,
Greg KH <gregkh@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/