On Tue, Jul 20, 2010 at 04:19:21AM -0400, Jean Delvare wrote: > Hi Henrique, > > On Mon, 19 Jul 2010 09:23:27 -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 19 Jul 2010, Jean Delvare wrote: > > > I guess you really meant: "only once per CPU"? > > > > > > This will be difficult and inconvenient to implement with the current > > > driver's strategy of having a separate hwmon entry for each core > > > temperature value. > > > > Which was clearly a bad design decision in hindsight. hwmon devices can > > have a large number of temperature sensors, and all of them can have > > kernel-issued labels for a good reason. > > I agree. If you dig the lm-sensors list, you'll see that I told Rudolf > I didn't like his driver design, a long time ago. But he claimed that > was the best way to handle hot-plugged CPUs... > > > > (...) > > > As said above, this isn't trivial. If you just add the sysfs attribute > > > to existing hwmon devices, you'll have duplicates. If you don't want > > > duplicates, you'll get an asymmetry (an arbitrary hwmon entry will get > > > the extra temperature, the user will get inevitably confused by this) > > > and the hotplug code will be difficult to deal with. > > > > IMHO, it would be best to consolidate them all into either a hwmon device > > per package, or a single hwmon for the entire coretemp driver. > > Guenter and myself seem to agree on a per-package approach. > > > Best put some mind grease on it to make sure it makes sense for NUMA and > > hybrid systems where you have more than one type of CPU, for future proofing > > (which at first glance seems to ask for a hwmon device per package, to > > consolidate all sensors for that package). > > > > > The most direct approach is probably to have a separate hwmon entry for > > > the package temperature. But I start feeling dizzy when looking at > > > these 8 coretemp hwmon entries I already have on my system, and adding > > > a couple more doesn't exactly please me. So it may be the right time to > > > start thinking of a different strategy - even though this comes with > > > backwards compatibility pain. > > > > Please do, it is well worth it. > > I will, later, if nobody beats me on it. It's relatively low on my > priority list though. > I might have some time to pick it up if no one else does. > > > But please keep in mind that libsensors applications are not notified > > > when sysfs attributes come and go at runtime, nor when hwmon entries > > > come and go. So in the end, hotplug needs a manual restart of all > > > monitoring applications for now anyway. > > > > That is a big bug in libsensors, which needs to be addressed anyway. > > Let's not go dramatic. This isn't a "big bug". This is a missing > feature. Anyone interested in that feature is welcome to contribute > code to support their use case. Me, I'm not using CPU hot-plug, so I > don't really care. > Especially since that someone should be able to test it. Maybe I should volunteer to do it if someone donates a board (preferrably with four 8-core intel CPUs ;-). Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
