linux-kernel - Re: [PATCH v2] Re: Battery class driver.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Nov 2006 11:31:34 -0800
From:	Greg KH <greg@...ah.com>
To:	Shem Multinymous <multinymous@...il.com>
Cc:	David Zeuthen <davidz@...hat.com>,
	Richard Hughes <hughsient@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Dan Williams <dcbw@...hat.com>, linux-kernel@...r.kernel.org,
	devel@...top.org, sfr@...b.auug.org.au, len.brown@...el.com,
	benh@...nel.crashing.org,
	linux-thinkpad mailing list <linux-thinkpad@...ux-thinkpad.org>,
	Pavel Machek <pavel@...e.cz>, Jean Delvare <khali@...ux-fr.org>
Subject: Re: [PATCH v2] Re: Battery class driver.

On Tue, Oct 31, 2006 at 03:28:27PM +0200, Shem Multinymous wrote:
> Hi Greg,
> 
> On 10/31/06, Greg KH <greg@...ah.com> wrote:
> >> On 10/28/06, David Zeuthen <davidz@...hat.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.

Then you should just get different sysfs files then.  One that describes
power and one that describes current.

> 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.

No, again, one for power and one for current.  Two different files
depending on the type of battery present.  That way there is no need to
worry about unit issues.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/