userspace regression with hwmon

Hi Guenter, Jean,

The patch d72d19c26c41 ("hwmon: (coretemp) Convert to use devm_hwmon_device_register_with_groups") has changed the location of the sysfs nodes from /sys/devices/platform/coretemp.0/ to /sys/devices/platform/coretemp.0/hwmon/hwmon0/ and that has broken some of our usespace applications when we have updated the kernel from v3.8 to v4.4. For now I am reverting that said patch in our production kernel (based on v4.4) but that is not an elegant solution. Do you have any other reports like this? I am sure changing the paths upstream will now break some other userspace. So, what can be an elegant solution to our problem? or do we always need to carry an out-of-tree patch for our production kernel?

Quoted 14 lines · Sudip Mukherjee

Hi Guenter, Jean,

The patch d72d19c26c41 ("hwmon: (coretemp) Convert to use devm_hwmon_device_register_with_groups") has changed the location of the sysfs nodes from /sys/devices/platform/coretemp.0/ to /sys/devices/platform/coretemp.0/hwmon/hwmon0/ and that has broken some of our usespace applications when we have updated the kernel from v3.8 to v4.4. For now I am reverting that said patch in our production kernel (based on v4.4) but that is not an elegant solution. Do you have any other reports like this? I am sure changing the paths upstream will now break some other userspace. So, what can be an elegant solution to our problem? or do we always need to carry an out-of-tree patch for our production kernel?

The problem only occurs if attributes are accessed using the raw path, and if user space does not take into account that attributes may reside in the hwmon directory (/sys/class/hwmon/hwmonX) _or_ in the device directory (/sys/class/hwmon/hwmonX/device). There is no guarantee that the raw path doesn't change from release to release; that is what the symlinks are for. Actually, I have seen the raw platform device path change over time, so I am surprised that this never affected you.

Quoted 16 lines · Guenter Roeck

Quoted 14 lines · Sudip Mukherjee

Hi Guenter, Jean,

The patch d72d19c26c41 ("hwmon: (coretemp) Convert to use devm_hwmon_device_register_with_groups") has changed the location of the sysfs nodes from /sys/devices/platform/coretemp.0/ to /sys/devices/platform/coretemp.0/hwmon/hwmon0/ and that has broken some of our usespace applications when we have updated the kernel from v3.8 to v4.4. For now I am reverting that said patch in our production kernel (based on v4.4) but that is not an elegant solution. Do you have any other reports like this? I am sure changing the paths upstream will now break some other userspace. So, what can be an elegant solution to our problem? or do we always need to carry an out-of-tree patch for our production kernel?

Quoted 7 lines

The problem only occurs if attributes are accessed using the raw path, and if user space does not take into account that attributes may reside in the hwmon directory (/sys/class/hwmon/hwmonX) _or_ in the device directory (/sys/class/hwmon/hwmonX/device). There is no guarantee that the raw path doesn't change from release to release; that is what the symlinks are for. Actually, I have seen the raw platform device path change over time, so I am surprised that this never affected you.

Well, using the raw platform device path was a bad design decision. But I still see a difference. In v3.8 all the temp* nodes were in /sys/class/hwmon/hwmon0/device/ but in v4.4 I can see that they are in /sys/class/hwmon/hwmon0/. So if we do modify the code, then we still need to have two versions of userspace code based on the kernel.

Quoted 5 lines · Sudip Mukherjee

Well, using the raw platform device path was a bad design decision. But I still see a difference. In v3.8 all the temp* nodes were in /sys/class/hwmon/hwmon0/device/ but in v4.4 I can see that they are in /sys/class/hwmon/hwmon0/. So if we do modify the code, then we still need to have two versions of userspace code based on the kernel.

Your code should check for the 'name' attribute in both locations.