Messages in this thread | | | Date | Tue, 31 Oct 2006 15:28:27 +0200 | From | "Shem Multinymous" <> | Subject | Re: [PATCH v2] Re: Battery class driver. |
| |
Hi Greg,
On 10/31/06, Greg KH <greg@kroah.com> wrote: > > On 10/28/06, David Zeuthen <davidz@redhat.com> wrote: > > >What about just prepending the unit to the 'threshold' file? Then user > > >space can expect the contents of said file to be of the form "%d %s". I > > >don't think that violates the "only one value per file" sysfs mantra. > > > > The tp_smapi battery driver did just this ("16495 mW"). But I dropped > > it in a recent version when Pavel pointed out the rest of sysfs, hwmon > > included, uses undecorated integers. > > Consistency aside, it seems reasonable and convenient. You have to > > decree that writes to the attributes (where relevant) don't include > > the units, of course, so no one will expect the kernel to parse that. > > > > There's an issue here if a drunk driver decides to specify (say) > > capacity_remaining in mWh and capacity_last_full in mAa, which will > > confuse anyone comparing those attributest. So don't do that. > > > > Jean, what's your opinion on letting hwmon-ish attributes specify > > units as "%d %s" where these are hardware-dependent? > > No, the sysfs files should just always keep the same units as > documented. It's easier all around that way.
It sure is easier, but we're discussinng the case where units change in runtime; what do we document then? Plug in a different battery and you get reports in mA and mAh insted of mW and mWh.
The suggestions so far were: 1. Append units string to the content of such attribute: /sys/.../capacity_remaining reads "16495 mW". 2. Add a seprate *_units attribute saying what are units for other attribute: /sys/.../capacity_units gives the units for /sys/.../capacity_{remaining,last_full,design,min,...}. 3. Append the units to the attribute names: capacity_{remaining,last_full,design_min,...}:mV.
Shem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |