Re: [ACPI] Re: 2.6.10-rc1-mm3: ACPI problem due to un-exported hotplug_path

[Greg KH]

On Tue, Nov 09, 2004 at 11:15:55PM -0500, Dmitry Torokhov wrote:
> On Tuesday 09 November 2004 07:08 pm, Greg KH wrote:
> > On Tue, Nov 09, 2004 at 06:48:17PM -0500, Dmitry Torokhov wrote:
> > > On Tue, 9 Nov 2004 14:55:02 -0800, Greg KH <greg@xxxxxxxxx> wrote:
> > > > On Fri, Nov 05, 2004 at 09:18:48PM -0800, Keshavamurthy Anil S wrote:
> > > > > Also, since you have brought this, I have one another question to you.
> > > > > Now in the new kernel, I see whenever anybody calls sysdev_register(kobj),
> > > > > an "ADD" notification is sent. why is this? I would like to call
> > > > > kobject_hotplug(kobj, ADD) later.
> > > > 
> > > > This happens when kobject_add() is called.  You shouldn't ever need to
> > > > call kobject_hotplug() for an add event yourself.
> > > > 
> > > 
> > > This is not always the case. One might want to postpone ADD event
> > > until all summpelental object attributes are created. This way userspace
> > > is presented with object in consistent state.
> > 
> > No, that's a mess.  Let userspace wait for those attributes to show up
> > if they need to.  That's what the "wait_for_sysfs" program bundled with
> > udev is for.
> >
> 
> I strongly disagree:
> 
> - it makes userspace being aware of implementation details (whe exactly it
>   has to wait for, for how long, etc.) which is bad thing;
> - not all the world is udev - needless replication of the code and bugs;
> - not only making visible but announcing an object in non-working state
>   to userspace simply does not feel right.

Based on the recent additions to the /sbin/hotplug environment
variables, userspace now knows exactly what it needs to wait for, if
anything.  

Also, there's no needless replication of this code, that's why
wait_for_sysfs was split off of udev, it's for everyone to use, if they
want to.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/