RE: ACPI buttons in 2.6.12-rc4-mm2

[Brown, Len]

>> I'm open to suggestions on how to approach this transition.
>> I can make ACPI_PROC a static build option -- what else
>> can I do to ease the transition in this, our stable release?
>
>Well I don't know how awkward this would be from an 
>implementation POV, but can we just leave the legacy
>/proc stuff there until the /sys interface is
>all in place and userspace is upgraded?
>Then kill all the /proc stuff later?
>
>We could also print a rude message the first time someone 
>tries to use a deprecated /proc file, just to help push the
>userspace tool developers along.
>Although I note that sys_bdflush() is still with us ;)

/proc/acpi/event
/proc/acpi/sleep
are used the most.

/proc/acpi/<drivername>/<BIOS devname>/* are really screwed up
in that <BIOS devname> is an arbitrary internal BIOS string
that should have never been exposed to userspace.  Instead
we should have done what sysfs does -- look at the _type_
of device and then simply add a number to it -- cpu0, cpu1
so that a program could actually find stuff.

I'm constantly nagged that this layer in the /proc/tree
had arbitrary strings in pathnames.  Also, the /proc
file handling code is buggy -- so it wastes my time
maintaining it, when it should not exist at all...
Restoring the /proc code to the button driver will
increase button.c in size by over 60%...

So I'm in favor of whatever solution makes it all go away
as soon as possible.

-Len
-
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/