linux-kernel - Re: [RFC] New kobject/kset/ktype documentation and example code

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]

Date:	Wed, 28 Nov 2007 16:57:48 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	Alan Stern <stern@...land.harvard.edu>,
	Jonathan Corbet <corbet@....net>,
	Randy Dunlap <randy.dunlap@...cle.com>
Subject: Re: [RFC] New kobject/kset/ktype documentation and example code

On Wed, 2007-11-28 at 16:48 +0100, Cornelia Huck wrote:
> On Wed, 28 Nov 2007 13:23:02 +0100,
> Kay Sievers <kay.sievers@...y.org> wrote:
> > On Wed, 2007-11-28 at 12:45 +0100, Cornelia Huck wrote:
> > > On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <greg@...ah.com> wrote:

> > > > The uevent function will be called when the uevent is about to be sent to
> > > > userspace to allow more environment variables to be added to the uevent.
> > > 
> > > It may be helpful to mention which uevents are by default created by
> > > the kobject core (KOBJ_ADD, KOBJ_DEL, KOBJ_MOVE).
> > 
> > I think, we should remove all these default events from the kobject
> > core. We will not be able to manage the timing issues and "raw" kobject
> > users should request the events on their own, when they are finished
> > adding stuff to the kobject. I see currently no way to solve the
> > "attributes created after the event" problem. The new
> > *_create_and_register functions do not allow default attributes to be
> > created, which will just lead to serious trouble when someone wants to
> > use udev to set defaults and such things. We may just want to require an
> > explicit call to send the event?
> 
> There will always be attributes that will show up later (for example,
> after a device is activated). Probably the best approach is to keep the
> default uevents, but have the attribute-adder send another uevent when
> they are done?

Uh, that's more an exception where we can't give guarantees because of
very specific hardware setups, and it would be an additional "change"
event. There are valid cases for this, but only a _very_ few.

There is absolutely no reason not to do it right with the "add" event,
just because we are too lazy to solve it proper the current code. It's
just so broken by design, what we are doing today. :)

Kay

-
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/