> ... need a consistent interface to common functionality. Agreed. Path names and file names in sysfs are an API, so it is important to choose them wisely. The string "acpi" should not appear in any path-name or file-name in sysfs that is intended to be generic, as it would make no sense on a non-ACPI system. Neither the ACPI /proc/acpi/battery API or the tp_smapi /sys/devices/platform/smapi API qualify as generic. It it a historical artifact that /proc/acpi exists, I'd delete it immediately if that wouldn't instantly break every distro on earth. Re: battery events Vojtech suggested that we create a virtual battery interface, just like the input layer has virtual input devices. Drivers such as above could conjur up devices, and user-space could also create what look like batteries, say through a utility that knows how to talk to a UPS. In either case, user-space would look for a well known set of device file names, such as /dev/battery0, /dev/battery1 or some such, do a select on the file and get events that way. With a /dev/battery0, and IOCTLS to get information from it, the question becomes redundancy between that file and sysfs text files. Re: sysfs or /dev It is tempting to claim that sysfs is extensible, but note that whenever you create a sysfs file, you are creating an API, which is a decision of exactly the same magnitude as defining an IOCTL -- in either case, user-space needs to react to it to understand it -- just that you can do that from the shell with sysfs. -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
