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:	Mon, 24 Jan 2011 14:07:47 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Thomas Renninger <trenn@...e.de>
Cc:	"R, Durgadoss" <durgadoss.r@...el.com>, jdelvare@...ell.com,
	"Zhang, Rui" <rui.zhang@...el.com>, Len Brown <lenb@...nel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Kay Sievers <kay.sievers@...y.org>,
	linux-perf-users@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-trace-users@...r.kernel.org
Subject: Re: Thermal kernel events API to userspace - Was: Re: thermal:
 Avoid CONFIG_NET compile dependency

On Mon, 24 Jan 2011, Thomas Renninger wrote:
> I wonder whether netlink is the way to go for thermal
> events at all.
> Sending an udev event would already contain the sysfs
> path to the thermal device. A variable which thermal event
> got thrown could get added and userspace can read out the rest
> easily from sysfs files. But I expect udev is not intended
> for such general events?

udev is heavyweight in the userspace side, we'd be much better off using the
ACPI event interface (which is netlink), or a new one to deliver system
status events, instead of continously abusing udev for this stuff.

> > > Also, the thermal_aux0 and _aux1, we can use the final format specified by you.
> > > enum events {
> > >  	THERMAL_CRITICAL,
> > >  	/* user defined thermal events */
> > >  	THERMAL_USER_AUX0,
> > >  	THERMAL_USER_AUX1,
> > >  	THERMAL_DEV_FAULT,
> > >  };

Please give us at least two levels of thermal alarm: critical and emergency
(or warning and critical -- it doesn't matter much, as long as there are at
least two levels, and which one comes first is defined by the
specification).  I'd have immediate use for them on thinkpads.

It is probably best to have three levels (warning, critical, emergency).
Best not to tie the API/ABI to the notion of "too hot", one can also alarm
when it starts to get to cold.

-- 
  "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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ