On Thu, 27 Jul 2006, Shem Multinymous wrote: > On 7/27/06, Brown, Len <len.brown@xxxxxxxxx> wrote: > > 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. > > Yes. But it looks like we'll have a hard time finding this common > interface, due to overlaps and omissions between battery drivers. Maybe it would be best to have a virtual driver that knows about the union of the features, and makes whatever features are provided by the underlying driver available to userspace. That way, all of the drivers are implementing features out of a shared set, so you don't end up with thinkpad/force_discharge and something/discharge_battery. This is the principle behind, for example, the generic cdrom driver, which doesn't actually implement much but rather provides uniformity across devices handled by different drivers. I don't think this is a case where each driver provides very similar functionality, but with critical differences which can't be corrected for; it seems like features are clearly available or not. Of course, userspace can figure out which features are available by checking which files exist in the sysfs directory. -Daniel *This .sig left intentionally blank* - 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
