Hi Guenter, On Mon, 21 Oct 2013 08:16:16 -0700, Guenter Roeck wrote: > I think it is more likely that the problem is related to parsing the 'subsystem' > link. If I understand the code in lib/sysfs.c correctly, it doesn't recognize > 'thermal' (which I think is the subsystem name, but I may be wrong) and ignores > the device as unknown. Yes, you are right, that's exactly what is happening here. > Question is if we can come up with some more generic code to handle that case. > Define SENSORS_BUS_TYPE_OTHER and treat it similar to virtual, maybe ? > But then there can be more than one of those, so you would need some means > for enumerating bus and chip numbers, so I don't know if that is feasible. The whole point of identifying the subsystem is because we want to assign a unique, stable identifier to each chip, and the naming scheme depends on the subsystem. If we start treating all unsupported subsystems as "other", we simply won't be able to give these devices unique names. Developers and users are unlikely to care and report the problem to us if libsensors shows them their "foo-other-0" device. This is why libsensors ignores these devices: developers and users will report about the missing device and we can add proper support to libsensors. That way we can get the naming scheme right immediately instead of later when this will break running configurations. Commit b82715fdd4a5407f56853b24d387d484dd9c3b5b is simply wrong, so it should be reverted. It assumes that there's a 1:1 mapping between thermal zones and hwmon devices, which is not the case. See this comment near the top of thermal_hwmon.c: /* thermal zone devices with the same type share one hwmon device */ So associating the hwmon device with the first registered thermal zone of its kind is arbitrary and asymmetric and makes no sense. I don't know what the goal of that change was, but that will have to be achieved in a different way. Note that merging all thermal zones of one kind into a single hwmon device is exactly what makes it possible to treat it as a virtual device and still guarantee uniqueness of the identifier (e.g. acpitz-virtual-0.) It has the drawback of leaving the input ordering stability up to the kernel, but back then it was not considered an issue. If we now want to have one hwmon device per thermal zone, then the kernel must provide a way for libsensors to give each of them a unique and stable identifier. Naming scheme is relatively free. Note that I am not necessarily in favor of such a change, as 1* it could lead to a huge number of hwmon devices, making the output of "sensors" harder to read, and 2* the change could break existing configurations. So if anyone wants to change this, a really really good reason must be provided, i.e. you will have to demonstrate that the benefits outweigh the pain. Hope it helps, -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
