[PATCH 0/5] ACPI: procfs/sysfs/debugfs code cleanup

[PATCH 0/5] ACPI: procfs/sysfs/debugfs code cleanup

[Zhang Rui]

This patch set mainly cleans up the ACPI procfs/sysfs/debugfs code.

1. removes the deprecated ACPI procfs I/F, including
   /proc/acpi/debug_layer
   /proc/acpi/debug_level
   /proc/acpi/info
   /proc/acpi/dsdt
   /proc/acpi/fadt
   because the sysfs I/F have been working for years without any problems.

2. introduce drivers/acpi/debugfs.c, code for ACPI debugfs I/F, i.e.
   /sys/kernel/debug/acpi/custom_method,
   are moved to this file.

3. introduce drivers/acpi/sysfs.c, code for ACPI sysfs I/F, including
   /sys/module/acpi/parameters/debug_layer,
   /sys/module/acpi/parameters/debug_level,
   /sys/module/acpi/parameters/acpica_version,
   /sys/firmware/acpi/interrupts/*,
   /sys/firmware/acpi/tables/*,
   are moved to this file.

4. introduce module parameter acpi.aml_debug, which is an enhancement of
   the runtime custom method overriding mechanism.

any comments are welcome.

thanks,
rui

Re: [PATCH 0/5] ACPI: procfs/sysfs/debugfs code cleanup

[Len Brown]

On Fri, 11 Jun 2010, Zhang Rui wrote:

> This patch set mainly cleans up the ACPI procfs/sysfs/debugfs code.
> 
> 1. removes the deprecated ACPI procfs I/F, including
>    /proc/acpi/debug_layer
>    /proc/acpi/debug_level
>    /proc/acpi/info
>    /proc/acpi/dsdt
>    /proc/acpi/fadt
>    because the sysfs I/F have been working for years without any problems.

Documentation/feature-removal-schedule.txt has warned
that we'd delete all of /proc/acpi/ for a long time now,
but we seem to have somewhat stalled out on that quest.

After this patch series, it seems like a good time to take inventory
of /proc/acpi/, list every file, and list if and when it will go away..
A section in feature-removal-schedule.txt is probably as good a place
as any for this.

Files that are deprecated should all be put under CONFIG_ACPI_PROCFS
where they should wait to be deleted for at least one release.

(Also, this patch series needs to update drivers/acpi/Kconfig comments
 because it removes some files that were aging under CONFIG_ACPI_PROCFS)

/proc/acpi/event was deemed too special to age under
CONFIG_ACPI_PROCFS, and so it has its own CONFIG_ACPI_PROC_EVENT
I think losing its default =y now would make sense,
and move it under CONFIG_ACPI_PROCFS in a year?
and hopefully delete it entirely in another year?

CONFIG_PROCFS_POWER should proably now also lose its default =y.
If current user-space no longer needs this, then
in a few releases it can get sucked under CONFIG_ACPI_PROCFS.

About 50% of button.c is suport for /proc/acpi/button/* --
it will be satisfying to simplify that one.
We tried to delete that code once, but somebody reads
the lid status, and so we restored it.
I don't know if we can get the LID status from anyplace else,
so that file may have to remain longer, but the other
/proc/acpi/button files are useuless and can go in 1 release.

thanks,
Len Brown, Intel Open Source Technology Center

Re: [PATCH 0/5] ACPI: procfs/sysfs/debugfs code cleanup

[Zhang Rui]

On Sat, 2010-06-12 at 00:48 +0800, Len Brown wrote:
> On Fri, 11 Jun 2010, Zhang Rui wrote:
> 
> > This patch set mainly cleans up the ACPI procfs/sysfs/debugfs code.
> > 
> > 1. removes the deprecated ACPI procfs I/F, including
> >    /proc/acpi/debug_layer
> >    /proc/acpi/debug_level
> >    /proc/acpi/info
> >    /proc/acpi/dsdt
> >    /proc/acpi/fadt
> >    because the sysfs I/F have been working for years without any problems.
> 
> Documentation/feature-removal-schedule.txt has warned
> that we'd delete all of /proc/acpi/ for a long time now,
> but we seem to have somewhat stalled out on that quest.
> 
> After this patch series, it seems like a good time to take inventory
> of /proc/acpi/, list every file, and list if and when it will go away..
> A section in feature-removal-schedule.txt is probably as good a place
> as any for this.
> 
> Files that are deprecated should all be put under CONFIG_ACPI_PROCFS
> where they should wait to be deleted for at least one release.
> 
> (Also, this patch series needs to update drivers/acpi/Kconfig comments
>  because it removes some files that were aging under CONFIG_ACPI_PROCFS)
> 
Agree.

> /proc/acpi/event was deemed too special to age under
> CONFIG_ACPI_PROCFS, and so it has its own CONFIG_ACPI_PROC_EVENT

Do you know any progress about this?
is acpid going to switch to netlink events or anything else?

> I think losing its default =y now would make sense,

We may got a lot of bug reports if acpid can not catch the ACPI events
any more...

> and move it under CONFIG_ACPI_PROCFS in a year?
> and hopefully delete it entirely in another year?
> 
> CONFIG_PROCFS_POWER should proably now also lose its default =y.
> If current user-space no longer needs this, then
> in a few releases it can get sucked under CONFIG_ACPI_PROCFS.
> 
question is that does user-space still need this?
how does the current Ubuntu/Fedora get the AC/Battery status?

> About 50% of button.c is suport for /proc/acpi/button/* --
> it will be satisfying to simplify that one.
> We tried to delete that code once, but somebody reads
> the lid status, and so we restored it.
> I don't know if we can get the LID status from anyplace else,

we can add sysfs I/F for button drivers as the last choice, if we can
not get the lid status via input layer or any other place generic.

> so that file may have to remain longer, but the other
> /proc/acpi/button files are useuless and can go in 1 release.
> 
Agree.

thanks,
rui