> ... 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-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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
