From: Brown, L. <len...@in...> - 2005-07-27 23:41:34
|
=20 >> 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=20 >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=20 >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 |