Hi Rui, On Tue, 18 Mar 2008 09:59:29 +0800, Zhang, Rui wrote: > On Mon, 2008-03-17 at 20:37 +0800, Jean Delvare wrote: > > I am sorry that I did not notice when you suggested this. I disagree, > > but now Rui's code is upstream so I guess it's too late to complain. > > Still here are my reasons: > > > > One of the great things about libsensors is that it gives unique names > > to hardware monitoring devices, and for each device, each feature has > > a > > unique name as well. This makes it possible to ignore or label a > > specific feature in /etc/sensors.conf in a way that is stable over > > reboot and addition of new hardware. > Interesting. > > > By going with a single virtual device for all thermal zones, you break > > this model. Depending on which thermal zone drivers are loaded and in > > which order they are loaded, there will be more or less temp* files in > > the hwmon directory and you also can't predict their order. > Yes, you're right. > > > The > > labelling issue could be solved by adding temp*_label files, but this > > still prevents the user from overriding a label. > why user needs to override the label? Originally, the kernel drivers don't provide any labels (because they don't know which temperature sensor corresponds to what) so the default labels are temp1, temp2, temp3 etc. The users instead what to see "CPU Temp", "M/B Temp" etc. which is why libsensors makes it possible to associate a label to each input. If a given kernel driver knows what temperature sensors correspond to, then this driver could propose a label. However there are many reasons why the user may want to override the proposed label: * The BIOS is broken and mislabeled the zone. * The default label is too long and doesn't fit it some graphical interface. * The user wants to translate the text to his/her native language. * Different thermal zones end up with the same label and the user wants to differentiate them. > > And there's no way to > > reliably ignore a specific thermal zone or to ask for information > > about a specific thermal zone with the current model. > > > > For this reason, I think it would be much better to have one hwmon > > class device for each _type_ of thermal zone. > Well. I disagree. > First, the generic thermal driver only checks the callbacks and builds > the sys I/F for each thermal zone registered. So there is no difference > between different thermal zones. Checking the type of different thermal > zone and register a hwmon device for each _type of thermal zones doesn't > make sense to me. :( The type of the thermal zone is known to the generic thermal driver somehow, as it exposes the information through the "type" sysfs file. I understand that it doesn't make any difference between different types other than that, but as long as it can differentiate between them, it could create different hwmon devices. Whether we want to do it or not, can be discussed of course. > Second, take ACPI thermal zone for example, the number/order of the ACPI > thermal zones can not be predicted either. All of this information is > gotten during system boot time. The number/order of the ACPI thermal zones is stable accross reboots, isn't it? That's all we really care about. > > > For example, all ACPI > > thermal zones would be listed as one hwmon class device. If we later > > add support for another type of thermal zones, all thermal zones of > > this type would be listed as one (different) hwmon class device. This > > makes each specific thermal zone driver responsible for the stability > > of the numbering of the various thermal zones of a given type. This > > would also let us give names to the different thermal zone types (e.g. > > "acpitz" for ACPI thermal zones) so that the users and supporters have > > an idea who is providing these temperature values and limits. > If we really need to do this, I suggest we do this in the native driver. > Say acpi thermal driver is responsible for registering a hwmon device > for ACPI thermal zones, just like the other hwmon native sensor drivers. > what do you think? That's what I wanted to do originally, before you showed up with this generic thermal driver. Of course each native thermal zone driver could register its own hwmon interface. This will however cause code duplication. I don't really care (I doubt there will be that many different native thermal zone drivers anyway), it's really up to you how you want to implement it, as long as it integrates properly with libsensors. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
