/proc/acpi/ removal plan

/proc/acpi/ removal plan

[Len Brown]

Rui,
Please look over these slides that I produced
for the Linux Plumber's Conference showing
where everything in /proc/acpi/ will go.

http://userweb.kernel.org/~lenb/doc/LPC2008-API-web/

Please let me know now if I've missed anything,
for I'll be speaking to them in the morning.

thanks,
-Len

Re: /proc/acpi/ removal plan

[Zhang Rui]

On Thu, 2008-09-18 at 14:32 +0800, Len Brown wrote:
> Rui,
> Please look over these slides that I produced
> for the Linux Plumber's Conference showing
> where everything in /proc/acpi/ will go.
> 
> http://userweb.kernel.org/~lenb/doc/LPC2008-API-web/
> 
> Please let me know now if I've missed anything,
> for I'll be speaking to them in the morning.

Hi, len,

Page 7, processor throttling state I/F
As processor T-state is used for thermal control only,
processor t-state is mapped to a cooling_device's cooling_state
in the generic thermal driver, combined with the processor's p-state.
e.g.
# ls -l /sys/class/thermal/cooling_device0/
total 0
-rw-r--r-- 1 root root 4096 2008-09-18 15:20 cur_state
lrwxrwxrwx 1 root root    0 2008-09-18 15:20 device
-> ../../../devices/LNXSYSTM:00/ACPI0007:00   (it's a processor!!!)
-r--r--r-- 1 root root 4096 2008-09-18 15:20 max_state
drwxr-xr-x 2 root root    0 2008-09-18 15:20 power
lrwxrwxrwx 1 root root    0 2008-09-18 15:20 subsystem -> ../../thermal
-r--r--r-- 1 root root 4096 2008-09-18 15:20 type
-rw-r--r-- 1 root root 4096 2008-09-18 15:20 uevent

I'm not sure if we need another generic processor throttle control I/F.

Page 14, wakeup control,
/sys/devices/.../wakeup should be in the todo list. :)

Page 18, we should not put the video driver together with the platform
specific drivers?

Page 21, oops, I forget to add the dynamic tables... will do it soon, :)

Page 23, button sys I/F can be found at /sys/class/input/.
e.g.
# cat /sys/class/input/input*/device/hid 
LNXPWRBN
PNP0C0C

According to Alexey's comments, we don;t need sysfs I/F for ec.
some info like the data/command port address is printed in the dmesg
during ec initialization.
And I don't think we need to export the power resource device info to
user space.

thanks,
rui

Re: /proc/acpi/ removal plan

[Len Brown]

> processor throttling state I/F
> As processor T-state is used for thermal control only,
> processor t-state is mapped to a cooling_device's cooling_state
> in the generic thermal driver, combined with the processor's p-state.

> # ls -l /sys/class/thermal/cooling_device0/

When I scribble into cur_state
I do not see anything reflected in
/proc/acpi/processor/*/throttling

Also, max_state is 10, when surely my processor
has only 8 T-states.

If user-space can not provoke processor T-states via this I/F,
then those using the old /proc I/F will flag it as a regression
when it goes away.  (even if few should ever need it)

> wakeup control,
> /sys/devices/.../wakeup should be in the todo list. :)

I thought that Rafael said the wakeup file
in the device tree was working now -- at least
for PCI devices, no?

I think the biggest problem with sysfs wakeup is that every
device in the tree gets a wakeup file, even if it
has no wakeup capability...

> oops, I forget to add the dynamic tables... will do it soon, :)
That would be good.
For when we have dynamic tables, we'll be able to enhance
acpidump to collect them and we'll not have to do this manually
like we've been doing.

>  button sys I/F can be found at /sys/class/input/.
> e.g.
> # cat /sys/class/input/input*/device/hid 
> LNXPWRBN
> PNP0C0C

The /proc files for power and sleep buttons simply
told us what kind of button they were, just info, not API.

The functional one is PNP0C0D, the lid switch.
It is also reflected in /sys/class/input, but I don't
see a way to find from /sys the open/closed state
like we have in /proc.  (I ran into this when I tried
to delete the button /proc I/F some time ago).


re: ec and power_resource, I agree, they can go.

thanks,
-Len

RE: /proc/acpi/ removal plan

[Zhang, Rui]

>From: Len Brown [mailto:lenb@hera.kernel.org]
>Sent: Friday, September 19, 2008 12:33 AM
>To: dmitry.torokhov@gmail.com; linux-acpi@vger.kernel.org; rjw@sisk.pl; Zhang,
>Rui
>Subject: Re: /proc/acpi/ removal plan
>
>> processor throttling state I/F
>> As processor T-state is used for thermal control only,
>> processor t-state is mapped to a cooling_device's cooling_state
>> in the generic thermal driver, combined with the processor's p-state.
>
>> # ls -l /sys/class/thermal/cooling_device0/
>
>When I scribble into cur_state
>I do not see anything reflected in
>/proc/acpi/processor/*/throttling
>
>Also, max_state is 10, when surely my processor
>has only 8 T-states.
>
the cooling state of processor is a combination of p-state and t-state.
because reducing the frequency is preferred when system is overheat.
e.g cooling state 0 mean processor can be run in the maximum frequency, and it's in the T0 state. And cooling state 9 means processor is in the minimum frequency, T7 state.

>If user-space can not provoke processor T-states via this I/F,
>then those using the old /proc I/F will flag it as a regression
>when it goes away.  (even if few should ever need it)
>
>> wakeup control,
>> /sys/devices/.../wakeup should be in the todo list. :)
>
>I thought that Rafael said the wakeup file
>in the device tree was working now -- at least
>for PCI devices, no?
>
Rafael's patch did bind the "wakeup" file together with the ACPI device.
It calls the acpi_enable_wakeup_device_power of the ACPI device, but it doesn't touch the wakeup GPE at all. So, I don't think it actually works...

>I think the biggest problem with sysfs wakeup is that every
>device in the tree gets a wakeup file, even if it
>has no wakeup capability...
>
that's okay.
The wakeup file return null string if it doesn't have the wakeup ability.
To be honest, there is one thing that I'm still concerned about.
The wakeup file is a runtime device wakeup flag rather than a system wakeup flag.
i.e. "enabled" means that the device can be suspend/resumed at runtime.
It doesn't ensure that it can wakeup the system from a sleep state.
If /proc/acpi/wakeup is replaced by the /sys/devices/.../wakeup, users may be confused because the device can not wakeup the system even if the wakeup file is set to "enabled".

>
>>  button sys I/F can be found at /sys/class/input/.
>> e.g.
>> # cat /sys/class/input/input*/device/hid
>> LNXPWRBN
>> PNP0C0C
>
>The /proc files for power and sleep buttons simply
>told us what kind of button they were, just info, not API.
>
>The functional one is PNP0C0D, the lid switch.
>It is also reflected in /sys/class/input, but I don't
>see a way to find from /sys the open/closed state
>like we have in /proc.  (I ran into this when I tried
>to delete the button /proc I/F some time ago).
>
You're right. Lid device still needs such an I/F.

Thanks,
Rui

Re: /proc/acpi/ removal plan

[Dmitry Torokhov]

On Fri, Sep 19, 2008 at 10:12:25AM +0800, Zhang, Rui wrote:
> >
> >>  button sys I/F can be found at /sys/class/input/.
> >> e.g.
> >> # cat /sys/class/input/input*/device/hid
> >> LNXPWRBN
> >> PNP0C0C
> >
> >The /proc files for power and sleep buttons simply
> >told us what kind of button they were, just info, not API.
> >
> >The functional one is PNP0C0D, the lid switch.
> >It is also reflected in /sys/class/input, but I don't
> >see a way to find from /sys the open/closed state
> >like we have in /proc.  (I ran into this when I tried
> >to delete the button /proc I/F some time ago).
> >
> You're right. Lid device still needs such an I/F.
> 

Input devices do not export their state through sysfs (1 file per
every possible event would mean 100s of files per keyboard) but writing
an tiny utility to get thos information through /dev/input/event for
use by scripts should be trivial.

-- 
Dmitry

Re: /proc/acpi/ removal plan

[Rafael J. Wysocki]

On Friday, 19 of September 2008, Zhang, Rui wrote:
> >From: Len Brown [mailto:lenb@hera.kernel.org]
> >Sent: Friday, September 19, 2008 12:33 AM
> >To: dmitry.torokhov@gmail.com; linux-acpi@vger.kernel.org; rjw@sisk.pl; Zhang,
> >Rui
> >Subject: Re: /proc/acpi/ removal plan
> >
> >> processor throttling state I/F
> >> As processor T-state is used for thermal control only,
> >> processor t-state is mapped to a cooling_device's cooling_state
> >> in the generic thermal driver, combined with the processor's p-state.
> >
> >> # ls -l /sys/class/thermal/cooling_device0/
> >
> >When I scribble into cur_state
> >I do not see anything reflected in
> >/proc/acpi/processor/*/throttling
> >
> >Also, max_state is 10, when surely my processor
> >has only 8 T-states.
> >
> the cooling state of processor is a combination of p-state and t-state.
> because reducing the frequency is preferred when system is overheat.
> e.g cooling state 0 mean processor can be run in the maximum frequency, and it's in the T0 state. And cooling state 9 means processor is in the minimum frequency, T7 state.
> 
> >If user-space can not provoke processor T-states via this I/F,
> >then those using the old /proc I/F will flag it as a regression
> >when it goes away.  (even if few should ever need it)
> >
> >> wakeup control,
> >> /sys/devices/.../wakeup should be in the todo list. :)
> >
> >I thought that Rafael said the wakeup file
> >in the device tree was working now -- at least
> >for PCI devices, no?
> >
> Rafael's patch did bind the "wakeup" file together with the ACPI device.
> It calls the acpi_enable_wakeup_device_power of the ACPI device, but it
> doesn't touch the wakeup GPE at all. So, I don't think it actually works... 

Have you noticed that the GPEs are actually set up right before
entering the sleep state?  acpi_enable_wakeup_device() does that, so in fact
yes, it does work.

> 
> >I think the biggest problem with sysfs wakeup is that every
> >device in the tree gets a wakeup file, even if it
> >has no wakeup capability...
> >
> that's okay.
> The wakeup file return null string if it doesn't have the wakeup ability.
> To be honest, there is one thing that I'm still concerned about.
> The wakeup file is a runtime device wakeup flag rather than a system wakeup
> flag.  i.e. "enabled" means that the device can be suspend/resumed at
> runtime. 

No, it is _NOT_.  'enabled' means that the device is allowed to wake up the
system from a sleep state if so configured.

> It doesn't ensure that it can wakeup the system from a sleep state.
> If /proc/acpi/wakeup is replaced by the /sys/devices/.../wakeup, users may
> be confused because the device can not wakeup the system even if the wakeup
> file is set to "enabled".  

That is actually true, but OTOH there's no any 'binary' interface that can be
used for that, because for example network adapters can wake-up the system in
many different situations (ie. they can react to many different types of
packets).

To avoid the confusion, I started to change the wake-on-LAN ioctls of network
adapters so that they update the 'wakeup' flag whey the device is set up to
wake up.

> >>  button sys I/F can be found at /sys/class/input/.
> >> e.g.
> >> # cat /sys/class/input/input*/device/hid
> >> LNXPWRBN
> >> PNP0C0C
> >
> >The /proc files for power and sleep buttons simply
> >told us what kind of button they were, just info, not API.
> >
> >The functional one is PNP0C0D, the lid switch.
> >It is also reflected in /sys/class/input, but I don't
> >see a way to find from /sys the open/closed state
> >like we have in /proc.  (I ran into this when I tried
> >to delete the button /proc I/F some time ago).
> >
> You're right. Lid device still needs such an I/F.

This is correct, /proc/wakeup is necessary for devices like that.

Thanks,
Rafael

Re: /proc/acpi/ removal plan

[Zhang Rui]

On Fri, 2008-09-19 at 16:07 -0600, Rafael J. Wysocki wrote:
> On Friday, 19 of September 2008, Zhang, Rui wrote:
> > >From: Len Brown [mailto:lenb@hera.kernel.org]
> > >Sent: Friday, September 19, 2008 12:33 AM
> > >To: dmitry.torokhov@gmail.com; linux-acpi@vger.kernel.org; rjw@sisk.pl; Zhang,
> > >Rui
> > >Subject: Re: /proc/acpi/ removal plan
> > >
> > >> processor throttling state I/F
> > >> As processor T-state is used for thermal control only,
> > >> processor t-state is mapped to a cooling_device's cooling_state
> > >> in the generic thermal driver, combined with the processor's p-state.
> > >
> > >> # ls -l /sys/class/thermal/cooling_device0/
> > >
> > >When I scribble into cur_state
> > >I do not see anything reflected in
> > >/proc/acpi/processor/*/throttling
> > >
> > >Also, max_state is 10, when surely my processor
> > >has only 8 T-states.
> > >
> > the cooling state of processor is a combination of p-state and t-state.
> > because reducing the frequency is preferred when system is overheat.
> > e.g cooling state 0 mean processor can be run in the maximum frequency, and it's in the T0 state. And cooling state 9 means processor is in the minimum frequency, T7 state.
> >
> > >If user-space can not provoke processor T-states via this I/F,
> > >then those using the old /proc I/F will flag it as a regression
> > >when it goes away.  (even if few should ever need it)
> > >
> > >> wakeup control,
> > >> /sys/devices/.../wakeup should be in the todo list. :)
> > >
> > >I thought that Rafael said the wakeup file
> > >in the device tree was working now -- at least
> > >for PCI devices, no?
> > >
> > Rafael's patch did bind the "wakeup" file together with the ACPI device.
> > It calls the acpi_enable_wakeup_device_power of the ACPI device, but it
> > doesn't touch the wakeup GPE at all. So, I don't think it actually works...
> 
> Have you noticed that the GPEs are actually set up right before
> entering the sleep state?  acpi_enable_wakeup_device() does that, so in fact
> yes, it does work.
> 
acpi_enable_wakeup_device will enable all the valid wakeup GPEs, that's
why dev->wakeup.state.enabled is set when writing to /proc/acpi/wakeup.
And I don't think this flag is set in acpi_pm_device_sleep_wake,
or do I miss something?

> >
> > >I think the biggest problem with sysfs wakeup is that every
> > >device in the tree gets a wakeup file, even if it
> > >has no wakeup capability...
> > >
> > that's okay.
> > The wakeup file return null string if it doesn't have the wakeup ability.
> > To be honest, there is one thing that I'm still concerned about.
> > The wakeup file is a runtime device wakeup flag rather than a system wakeup
> > flag.  i.e. "enabled" means that the device can be suspend/resumed at
> > runtime.
> 
> No, it is _NOT_.  'enabled' means that the device is allowed to wake up the
> system from a sleep state if so configured.
> 

> > It doesn't ensure that it can wakeup the system from a sleep state.
> > If /proc/acpi/wakeup is replaced by the /sys/devices/.../wakeup, users may
> > be confused because the device can not wakeup the system even if the wakeup
> > file is set to "enabled".
> 
> That is actually true, but OTOH there's no any 'binary' interface that can be
> used for that, because for example network adapters can wake-up the system in
> many different situations (ie. they can react to many different types of
> packets).
> 

> To avoid the confusion, I started to change the wake-on-LAN ioctls of network
> adapters so that they update the 'wakeup' flag whey the device is set up to
> wake up.
> 
that would be great. :)

thanks,
rui

Re: /proc/acpi/ removal plan

[Rafael J. Wysocki]

On Monday, 22 of September 2008, Zhang Rui wrote:
> On Fri, 2008-09-19 at 16:07 -0600, Rafael J. Wysocki wrote:
> > On Friday, 19 of September 2008, Zhang, Rui wrote:
> > > >From: Len Brown [mailto:lenb@hera.kernel.org]
> > > >Sent: Friday, September 19, 2008 12:33 AM
> > > >To: dmitry.torokhov@gmail.com; linux-acpi@vger.kernel.org; rjw@sisk.pl; Zhang,
> > > >Rui
> > > >Subject: Re: /proc/acpi/ removal plan
> > > >
> > > >> processor throttling state I/F
> > > >> As processor T-state is used for thermal control only,
> > > >> processor t-state is mapped to a cooling_device's cooling_state
> > > >> in the generic thermal driver, combined with the processor's p-state.
> > > >
> > > >> # ls -l /sys/class/thermal/cooling_device0/
> > > >
> > > >When I scribble into cur_state
> > > >I do not see anything reflected in
> > > >/proc/acpi/processor/*/throttling
> > > >
> > > >Also, max_state is 10, when surely my processor
> > > >has only 8 T-states.
> > > >
> > > the cooling state of processor is a combination of p-state and t-state.
> > > because reducing the frequency is preferred when system is overheat.
> > > e.g cooling state 0 mean processor can be run in the maximum frequency, and it's in the T0 state. And cooling state 9 means processor is in the minimum frequency, T7 state.
> > >
> > > >If user-space can not provoke processor T-states via this I/F,
> > > >then those using the old /proc I/F will flag it as a regression
> > > >when it goes away.  (even if few should ever need it)
> > > >
> > > >> wakeup control,
> > > >> /sys/devices/.../wakeup should be in the todo list. :)
> > > >
> > > >I thought that Rafael said the wakeup file
> > > >in the device tree was working now -- at least
> > > >for PCI devices, no?
> > > >
> > > Rafael's patch did bind the "wakeup" file together with the ACPI device.
> > > It calls the acpi_enable_wakeup_device_power of the ACPI device, but it
> > > doesn't touch the wakeup GPE at all. So, I don't think it actually works...
> > 
> > Have you noticed that the GPEs are actually set up right before
> > entering the sleep state?  acpi_enable_wakeup_device() does that, so in fact
> > yes, it does work.
> > 
> acpi_enable_wakeup_device will enable all the valid wakeup GPEs, that's
> why dev->wakeup.state.enabled is set when writing to /proc/acpi/wakeup.
> And I don't think this flag is set in acpi_pm_device_sleep_wake,
> or do I miss something?

Actually, yes, you do. :-)

Please read the last paragraph of the changelog of
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=eb9d0fe40e313c0a74115ef456a2e43a6c8da72f

Thanks,
Rafael

Re: /proc/acpi/ removal plan

[Henrique de Moraes Holschuh]

Len,

Do we have a tentative timeframe for /proc/acpi to be gone for good?

That impacts thinkpad-acpi very much so, I'd appreciate knowing any such
dates as soon as possible...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh