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

[Kay Sievers <kay.sievers@vrfy.org>]

On Wed, 2007-11-28 at 17:12 +0100, Cornelia Huck wrote:
> On Wed, 28 Nov 2007 16:57:48 +0100,
> Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > 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@vrfy.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@kroah.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. :)
> 
> I'm worrying a bit about changes that impact the whole code tree in
> lots of places. I'd be fine with the device layer doing its uevent
> manually in device_add() at the very end, though. (This would allow
> drivers to add attributes in their probe function before the uevent,
> for example.)

The driver core does use the split already in most places, I did that
long ago. There are not too many (~20) users of kobject_register(), and
it's a pretty straight-forward change to change that to _init, _add,
_uevent, and get rid of that totally useless "convenience api".

I think there is no longer any excuse to keep that broken code around,
and even require to document that it's broken. The whole purpose of the
uevent is userspace consumption, which just doesn't work correctly with
the code we offer. The fix is trivial, and should be done now, and we no
longer need to fiddle around timing issues, just because we are too
lazy.

I propose the removal of _all_ funtions that have *register* in their
name, and always require the following sequence:
  _init()
  _add()
  _uevent(_ADD)

  _uevent(_REMOVE)
  _del()
  _put()

The _create_and_register() functions would become  _create_ and_add()
and will need an additional _uevent() call after they populated the
object.

Thanks,
Kay

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