>> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
