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

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

[Adrian Bunk]

The following error (compin from Linus' tree) is caused by the fact that 
hotplug_path is no longer EXPORT_SYMBOL'ed:


<--  snip  -->

if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.10-rc1-mm3; fi
WARNING: /lib/modules/2.6.10-rc1-mm3/kernel/drivers/acpi/container.ko needs unknown symbol hotplug_path

<--  snip  -->

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

[Greg KH]

On Fri, Nov 05, 2004 at 05:45:23PM +0100, Adrian Bunk wrote:
> The following error (compin from Linus' tree) is caused by the fact that 
> hotplug_path is no longer EXPORT_SYMBOL'ed:
> 
> 
> <--  snip  -->
> 
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.10-rc1-mm3; fi
> WARNING: /lib/modules/2.6.10-rc1-mm3/kernel/drivers/acpi/container.ko needs unknown symbol hotplug_path
> 
> <--  snip  -->

Hm, must be an -mm specific change that is causing this.  I don't see
this in the current tree.

Len, why would any ACPI code be wanting to get access to hotplug_path
directly?

thanks,

greg k-h

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

[Kay Sievers]

On Fri, Nov 05, 2004 at 10:05:13AM -0800, Greg KH wrote:
> On Fri, Nov 05, 2004 at 05:45:23PM +0100, Adrian Bunk wrote:
> > The following error (compin from Linus' tree) is caused by the fact that 
> > hotplug_path is no longer EXPORT_SYMBOL'ed:
> > 
> > 
> > <--  snip  -->
> > 
> > if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.10-rc1-mm3; fi
> > WARNING: /lib/modules/2.6.10-rc1-mm3/kernel/drivers/acpi/container.ko needs unknown symbol hotplug_path
> > 
> > <--  snip  -->
> 
> Hm, must be an -mm specific change that is causing this.  I don't see
> this in the current tree.
> 
> Len, why would any ACPI code be wanting to get access to hotplug_path
> directly?


I've found it. This wants to introduce a new direct /sbin/hotplug call,
with "add" and "remove" events, without sysfs support.

It should use class support or kobject_hotplug() instead.  Nobody should
fake hotplug events anymore, cause every other notification transport
will not get called (currently uevent over netlink).
  http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/broken-out/bk-acpi.patch

+static int
+container_run_sbin_hotplug(struct acpi_device *device, char *action)
+{
...
+	argv[i++] = hotplug_path;
+	argv[i++] = "container";
+	argv[i] = NULL;
...
+	i = 0;
+	envp[i++] = "HOME=/";
+	envp[i++] = "PATH=/sbin;/bin;/usr/sbin;/usr/bin";
+	envp[i++] = action_str;
+	envp[i++] = container_str;
+	envp[i++] = "PLATFORM=ACPI";
+	envp[i] = NULL;
...


Thanks,
Kay

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

[Ashok Raj]

On Fri, Nov 05, 2004 at 12:10:12PM -0800, Kay Sievers wrote:
> 
>    On Fri, Nov 05, 2004 at 10:05:13AM -0800, Greg KH wrote:
>    >  >  The  following  error (compin from Linus' tree) is caused by the
>    fact that
>    > > hotplug_path is no longer EXPORT_SYMBOL'ed:
>    > >
>    > >
>    > > <--  snip  -->
>    > >
>    >  >  if  [  -r  System.map  ];  then  /sbin/depmod  -ae -F System.map
>    2.6.10-rc1-mm3; fi
> 
>    I've  found  it.  This  wants  to introduce a new direct /sbin/hotplug
>    call,
>    with "add" and "remove" events, without sysfs support.
> 
>    It  should  use  class  support  or kobject_hotplug() instead.  Nobody
>    should
>    fake hotplug events anymore, cause every other notification transport
>    will not get called (currently uevent over netlink).
> 

we were discussing this exact thing recently.. we maybe able to clean this up.. here is why
we are doing this manual thingy...

When we support physical component hotplug, we want to create the sysfs entries, but that doesnt
mean the component (i.e CPU or memory) is hotplugged. The reason is for node level hotplug
there are sequencing requirements, memory needs to be brought up first before cpu, and also
the error handling/policy requirments which we want the user space to handle it and not from 
kernel side.


the sequence is when physical arrival of cpu is seen, we will just create a sysfs entry 
which will also send an add event (which really is just cpu arrival, and sysfs created). 

In our model the event is just consumed by the script cpu.agent, which would in turn decide and 
bring the cpu up by 

#echo 1> /sys/devices/system/cpu/cpu#/online

what apps really would care about is the ONLINE (which doesnt exist) event itself, and the 
OFFLINE. The ADD/REMOVE only indicate sysfs entries appear and disappear.

I dont know if adding ONLINE/OFFLINE is the right thing, or use the CHANGE notification 
to inform. 

This is an area that needs more though which is slightly different from how other devices are being handled.

Greg-kh/Rusty .. any suggestions


Cheers,
Ashok Raj
- Linux OS & Technology Team

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

[Greg KH]

On Fri, Nov 05, 2004 at 09:10:12PM +0100, Kay Sievers wrote:
> On Fri, Nov 05, 2004 at 10:05:13AM -0800, Greg KH wrote:
> > On Fri, Nov 05, 2004 at 05:45:23PM +0100, Adrian Bunk wrote:
> > > The following error (compin from Linus' tree) is caused by the fact that 
> > > hotplug_path is no longer EXPORT_SYMBOL'ed:
> > > 
> > > 
> > > <--  snip  -->
> > > 
> > > if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.10-rc1-mm3; fi
> > > WARNING: /lib/modules/2.6.10-rc1-mm3/kernel/drivers/acpi/container.ko needs unknown symbol hotplug_path
> > > 
> > > <--  snip  -->
> > 
> > Hm, must be an -mm specific change that is causing this.  I don't see
> > this in the current tree.
> > 
> > Len, why would any ACPI code be wanting to get access to hotplug_path
> > directly?
> 
> 
> I've found it. This wants to introduce a new direct /sbin/hotplug call,
> with "add" and "remove" events, without sysfs support.
> 
> It should use class support or kobject_hotplug() instead.  Nobody should
> fake hotplug events anymore, cause every other notification transport
> will not get called (currently uevent over netlink).
>   http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/broken-out/bk-acpi.patch
> 
> +static int
> +container_run_sbin_hotplug(struct acpi_device *device, char *action)
> +{
> ...
> +	argv[i++] = hotplug_path;
> +	argv[i++] = "container";
> +	argv[i] = NULL;
> ...
> +	i = 0;
> +	envp[i++] = "HOME=/";
> +	envp[i++] = "PATH=/sbin;/bin;/usr/sbin;/usr/bin";
> +	envp[i++] = action_str;
> +	envp[i++] = container_str;
> +	envp[i++] = "PLATFORM=ACPI";
> +	envp[i] = NULL;
> ...

Good catch.  Yeah, that code is just wrong.

Anil, your name is on this file.  Care to fix it up to use the proper
driver core hotplug functionality instead of rolling your own?

Or is there some reason you are wanting to do this kind of notification
that the driver core is not providing for you?

thanks,

greg k-h

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

[Greg KH]

On Fri, Nov 05, 2004 at 12:32:56PM -0800, Ashok Raj wrote:
> On Fri, Nov 05, 2004 at 12:10:12PM -0800, Kay Sievers wrote:
> > 
> >    On Fri, Nov 05, 2004 at 10:05:13AM -0800, Greg KH wrote:
> >    >  >  The  following  error (compin from Linus' tree) is caused by the
> >    fact that
> >    > > hotplug_path is no longer EXPORT_SYMBOL'ed:
> >    > >
> >    > >
> >    > > <--  snip  -->
> >    > >
> >    >  >  if  [  -r  System.map  ];  then  /sbin/depmod  -ae -F System.map
> >    2.6.10-rc1-mm3; fi
> > 
> >    I've  found  it.  This  wants  to introduce a new direct /sbin/hotplug
> >    call,
> >    with "add" and "remove" events, without sysfs support.
> > 
> >    It  should  use  class  support  or kobject_hotplug() instead.  Nobody
> >    should
> >    fake hotplug events anymore, cause every other notification transport
> >    will not get called (currently uevent over netlink).
> > 
> 
> we were discussing this exact thing recently.. we maybe able to clean this up.. here is why
> we are doing this manual thingy...
> 
> When we support physical component hotplug, we want to create the sysfs entries, but that doesnt
> mean the component (i.e CPU or memory) is hotplugged. The reason is for node level hotplug
> there are sequencing requirements, memory needs to be brought up first before cpu, and also
> the error handling/policy requirments which we want the user space to handle it and not from 
> kernel side.
> 
> 
> the sequence is when physical arrival of cpu is seen, we will just create a sysfs entry 
> which will also send an add event (which really is just cpu arrival, and sysfs created). 
> 
> In our model the event is just consumed by the script cpu.agent, which would in turn decide and 
> bring the cpu up by 
> 
> #echo 1> /sys/devices/system/cpu/cpu#/online
> 
> what apps really would care about is the ONLINE (which doesnt exist) event itself, and the 
> OFFLINE. The ADD/REMOVE only indicate sysfs entries appear and disappear.
> 
> I dont know if adding ONLINE/OFFLINE is the right thing, or use the CHANGE notification 
> to inform. 

That's fine.  But call kobject_hotplug() if you want to do that.  Don't
rewrite your own function, or you will loose out on a lot of the hotplug
functionality (sequence numbers, kevent notifications, etc.)

thanks,

greg k-h

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

[Kay Sievers]

On Fri, Nov 05, 2004 at 12:32:56PM -0800, Ashok Raj wrote:
> On Fri, Nov 05, 2004 at 12:10:12PM -0800, Kay Sievers wrote:
> > 
> >    On Fri, Nov 05, 2004 at 10:05:13AM -0800, Greg KH wrote:
> >    >  >  The  following  error (compin from Linus' tree) is caused by the
> >    fact that
> >    > > hotplug_path is no longer EXPORT_SYMBOL'ed:
> >    > >
> >    > >
> >    > > <--  snip  -->
> >    > >
> >    >  >  if  [  -r  System.map  ];  then  /sbin/depmod  -ae -F System.map
> >    2.6.10-rc1-mm3; fi
> > 
> >    I've  found  it.  This  wants  to introduce a new direct /sbin/hotplug
> >    call,
> >    with "add" and "remove" events, without sysfs support.
> > 
> >    It  should  use  class  support  or kobject_hotplug() instead.  Nobody
> >    should
> >    fake hotplug events anymore, cause every other notification transport
> >    will not get called (currently uevent over netlink).
> > 
> 
> we were discussing this exact thing recently.. we maybe able to clean this up.. here is why
> we are doing this manual thingy...
> 
> When we support physical component hotplug, we want to create the sysfs entries, but that doesnt
> mean the component (i.e CPU or memory) is hotplugged. The reason is for node level hotplug
> there are sequencing requirements, memory needs to be brought up first before cpu, and also
> the error handling/policy requirments which we want the user space to handle it and not from 
> kernel side.
> 
> 
> the sequence is when physical arrival of cpu is seen, we will just create a sysfs entry 
> which will also send an add event (which really is just cpu arrival, and sysfs created). 
> 
> In our model the event is just consumed by the script cpu.agent, which would in turn decide and 
> bring the cpu up by 
> 
> #echo 1> /sys/devices/system/cpu/cpu#/online
> 
> what apps really would care about is the ONLINE (which doesnt exist) event itself, and the 
> OFFLINE. The ADD/REMOVE only indicate sysfs entries appear and disappear.
> 
> I dont know if adding ONLINE/OFFLINE is the right thing, or use the CHANGE notification 
> to inform. 
> 
> This is an area that needs more though which is slightly different from how other devices are being handled.

There is already an "offline" event used for cpu's in drivers/base/cpu.c.
It was recently converted from calling /sbin/hotplug directly :)

ChangeSet: 1.2021
http://linus.bkbits.net:8080/linux-2.5/patch@1.2021?nav=index.html|src/|src/kernel|related/kernel/cpu.c|cset@1.2021

Kay

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

[Keshavamurthy Anil S]

On Fri, Nov 05, 2004 at 12:42:09PM -0800, Greg KH wrote:
> On Fri, Nov 05, 2004 at 09:10:12PM +0100, Kay Sievers wrote:
> > On Fri, Nov 05, 2004 at 10:05:13AM -0800, Greg KH wrote:
> > > On Fri, Nov 05, 2004 at 05:45:23PM +0100, Adrian Bunk wrote:
> > > > The following error (compin from Linus' tree) is caused by the fact that 
> > > > hotplug_path is no longer EXPORT_SYMBOL'ed:
> > > > 
> > > > 
> > > > <--  snip  -->
> > > > 
> > > > if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.10-rc1-mm3; fi
> > > > WARNING: /lib/modules/2.6.10-rc1-mm3/kernel/drivers/acpi/container.ko needs unknown symbol hotplug_path
> > > > 
> > > > <--  snip  -->
> > > 
> > > Hm, must be an -mm specific change that is causing this.  I don't see
> > > this in the current tree.
> > > 
> > > Len, why would any ACPI code be wanting to get access to hotplug_path
> > > directly?
> > 
> > 
> > I've found it. This wants to introduce a new direct /sbin/hotplug call,
> > with "add" and "remove" events, without sysfs support.
> > 
> > It should use class support or kobject_hotplug() instead.  Nobody should
> > fake hotplug events anymore, cause every other notification transport
> > will not get called (currently uevent over netlink).
> >   http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/broken-out/bk-acpi.patch
> > 
> > +static int
> > +container_run_sbin_hotplug(struct acpi_device *device, char *action)
> > +{
> > ...
> > +	argv[i++] = hotplug_path;
> > +	argv[i++] = "container";
> > +	argv[i] = NULL;
> > ...
> > +	i = 0;
> > +	envp[i++] = "HOME=/";
> > +	envp[i++] = "PATH=/sbin;/bin;/usr/sbin;/usr/bin";
> > +	envp[i++] = action_str;
> > +	envp[i++] = container_str;
> > +	envp[i++] = "PLATFORM=ACPI";
> > +	envp[i] = NULL;
> > ...
> 
> Good catch.  Yeah, that code is just wrong.
> 
> Anil, your name is on this file.  Care to fix it up to use the proper
> driver core hotplug functionality instead of rolling your own?
> 
> Or is there some reason you are wanting to do this kind of notification
> that the driver core is not providing for you?
Greg,
	Yes, I agree what you say, we need to use class support or kobject_hotplug().
But in this case "a container object" gets added and this container object has
no direct representation in sysfs. So in this case can you please tell me 
what is the best thing to notify user.agent. Sorry I had looked some really old examples when I
wrote this driver.

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.

thanks,
Anil
> 
> thanks,
> 
> greg k-h

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

[Dmitry Torokhov]

On Saturday 06 November 2004 12:18 am, 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.
> 

Hi Anil,

Please take a look at drivers/base/firmware_class.c to see how one can
suppress initial hotplug notification and call hotplug when object is
finally ready. Hopefully you can use similar solution.

-- 
Dmitry

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

[Greg KH]

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.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

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

[Dmitry Torokhov]

On Tue, 9 Nov 2004 14:55:02 -0800, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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.

-- 
Dmitry


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

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

[Greg KH]

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-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

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

[Dmitry Torokhov]

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-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 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.

-- 
Dmitry


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

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@kroah.com> 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