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. > > > > > It is a really good idea to never expose through sysfs something that > > > > > isn't there. Alternatively, you can return errors like ENXIO, but you > > > > > should only do that when you have no other choice (because, e.g. you > > > > > cannot know beforehand whether a sensor will be available or not). > > +1 > > > > > > If one can detect when processor packages and cores come and go, and one > > > > > can ask the package and cores about the sensors that are really > > > > > available, one can expose to sysfs just the sensors that are > > > > > operational, and remove or add sensors when needed. > > I think we only see cores come and go, not packages = (physical CPUs). > The driver would have to track the cores. When the last core from a > given package goes away, we claim the package to be gone. Likewise, > when a core shows up with a physical id we didn't have yet, we claim > the package just came in. Looks like it, yes. > > > entry if there is. Plus, make sure that it is only created once. > > 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. 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. > 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. -- "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 _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
