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

[Zhang Rui <rui.zhang@intel.com>]

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