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]

Message-ID: <20061028215424.GA23228@khazad-dum.debian.net>
Date:	Sat, 28 Oct 2006 18:54:25 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Pavel Machek <pavel@....cz>
Cc:	David Zeuthen <davidz@...hat.com>,
	Richard Hughes <hughsient@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Shem Multinymous <multinymous@...il.com>,
	Dan Williams <dcbw@...hat.com>, linux-kernel@...r.kernel.org,
	devel@...top.org, sfr@...b.auug.org.au, len.brown@...el.com,
	greg@...ah.com, benh@...nel.crashing.org,
	linux-thinkpad mailing list <linux-thinkpad@...ux-thinkpad.org>
Subject: Re: [PATCH v2] Re: Battery class driver.

On Sat, 28 Oct 2006, Pavel Machek wrote:
> > > Just put it into the name:
> > > 
> > > power_avg_mV
> > 
> > Bad idea... it means user space will have to try to open different files
> > and what happens when someone introduces a new unit? Ideally I'd like
> > the unit to be part of the payload of the sysfs file. Second to that I
> > think having the unit in a separate file is preferable.
> 
> Introducing new unit *should* be hard. You know, when you introduce
> new unit, you automatically break all the userspace.

Well, I just wish whatever is done for battery is also done the same way for
ACPI when it moves to sysfs, and if at all possible, also to hwmon: we *are*
supposed to move stuff like ACPI temperatures to sysfs using hwmon
conventions, AFAIK.

That said, wearing a userspace app writer hat, I'd really prefer if it is
named in such a way that I can always extract the unit, like:

power_avg:mV  or
power_avg[mV]

or whatever (and I'd prefer :mV a lot more than [mV], it is much cleaner).
LED seems already to be using ":" for such qualifiers (they use it for the
colors).

I can't just trust that the last _foo is the unit, as it might be something
that doesn't have an unit (it is the status quo in hwmon, for example).  If
the kernel has this unit handling thing clearly defined, I can write a
generic application that displays all battery attributes beautifully,
instantly aware of the units (and even doing the intelligent thing if you
have both power_avg in uV and mV...)

> Having separate files is actually a *feature*. It allows you to
> introduce new units while providing backwards compatibility.

Agreed.

> Imagine going from mV to uV... With voltage_mV, you can have both
> voltage_mV and voltage_uV. In your system, you'd have to change value
> from mV to uV, breaking all the userspace....

I believe there is a school that says that "this is why userspace is
supposed to use a single library helper which will have the knowledge on how
to deal with this".

I am not defending such a library approach.  But if the sysfs interface does
not have the units anywhere, it better be strictly versioned and export
that information somewhere, so that such a library is actually doable in a
sane and robust way.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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/