coretemp.0 folder contents changed

coretemp.0 folder contents changed

[Srinivas Pandruvada]

Hi,

for kernel : 3.15.rc3 .

Is there any change in the coretemp? Previously we used to see, tempx 
data (like temp2_input, temp2_max etc.)
/sys/devices/platform/coretemp.0/.

Now We don't see them. Now we have to go 
/sys/devices/platform/coretemp.0/hwmon/hwmon?/ to get these values.

Thanks,
Srinivas

[lm-sensors] coretemp.0 folder contents changed

[Srinivas Pandruvada]

Hi,

for kernel : 3.15.rc3 .

Is there any change in the coretemp? Previously we used to see, tempx 
data (like temp2_input, temp2_max etc.)
/sys/devices/platform/coretemp.0/.

Now We don't see them. Now we have to go 
/sys/devices/platform/coretemp.0/hwmon/hwmon?/ to get these values.

Thanks,
Srinivas


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: coretemp.0 folder contents changed

[Guenter Roeck]

On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
> Hi,
> 
> for kernel : 3.15.rc3 .
> 
> Is there any change in the coretemp? Previously we used to see,
> tempx data (like temp2_input, temp2_max etc.)
> /sys/devices/platform/coretemp.0/.
> 
That isn't where you are supposed to look for hwmon attributes.

> Now We don't see them. Now we have to go
> /sys/devices/platform/coretemp.0/hwmon/hwmon?/ to get these values.
> 
This is also not the correct location.

You should be looking in /sys/class/hwmon/hwmonX/.

There will be a name attribute either in /sys/class/hwmon/hwmonX/name
or in /sys/class/hwmon/hwmonX/device/name. For coretemp, the value
reported in the name attribute will be 'coretemp'. This defines the
directory where the actual sensor attributes will be located.

A better approach might be to use libsensors instead of directly
accessing attributes.

To give you the background, hwmon attributes are in the process of
being moved from the parent device to the hwmon device, or from
/sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
as part of an effort to streamline the code and make it more
consistent and maintainable.

Guenter

Re: [lm-sensors] coretemp.0 folder contents changed

[Guenter Roeck]

On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
> Hi,
> 
> for kernel : 3.15.rc3 .
> 
> Is there any change in the coretemp? Previously we used to see,
> tempx data (like temp2_input, temp2_max etc.)
> /sys/devices/platform/coretemp.0/.
> 
That isn't where you are supposed to look for hwmon attributes.

> Now We don't see them. Now we have to go
> /sys/devices/platform/coretemp.0/hwmon/hwmon?/ to get these values.
> 
This is also not the correct location.

You should be looking in /sys/class/hwmon/hwmonX/.

There will be a name attribute either in /sys/class/hwmon/hwmonX/name
or in /sys/class/hwmon/hwmonX/device/name. For coretemp, the value
reported in the name attribute will be 'coretemp'. This defines the
directory where the actual sensor attributes will be located.

A better approach might be to use libsensors instead of directly
accessing attributes.

To give you the background, hwmon attributes are in the process of
being moved from the parent device to the hwmon device, or from
/sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
as part of an effort to streamline the code and make it more
consistent and maintainable.

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: coretemp.0 folder contents changed

[Srinivas Pandruvada]

On 05/05/2014 10:32 AM, Guenter Roeck wrote:
> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
>> Hi,
>>
>> for kernel : 3.15.rc3 .
>>
>> Is there any change in the coretemp? Previously we used to see,
>> tempx data (like temp2_input, temp2_max etc.)
>> /sys/devices/platform/coretemp.0/.
>>
> That isn't where you are supposed to look for hwmon attributes.
>
>> Now We don't see them. Now we have to go
>> /sys/devices/platform/coretemp.0/hwmon/hwmon?/ to get these values.
>>
> This is also not the correct location.
>
> You should be looking in /sys/class/hwmon/hwmonX/.
>
> There will be a name attribute either in /sys/class/hwmon/hwmonX/name
> or in /sys/class/hwmon/hwmonX/device/name. For coretemp, the value
> reported in the name attribute will be 'coretemp'. This defines the
> directory where the actual sensor attributes will be located.
>
> A better approach might be to use libsensors instead of directly
> accessing attributes.
>
> To give you the background, hwmon attributes are in the process of
> being moved from the parent device to the hwmon device, or from
> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
> as part of an effort to streamline the code and make it more
> consistent and maintainable.
>
> Guenter
>
Thanks for your quick reply.

-Srinivas

Re: [lm-sensors] coretemp.0 folder contents changed

[Srinivas Pandruvada]

On 05/05/2014 10:32 AM, Guenter Roeck wrote:
> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
>> Hi,
>>
>> for kernel : 3.15.rc3 .
>>
>> Is there any change in the coretemp? Previously we used to see,
>> tempx data (like temp2_input, temp2_max etc.)
>> /sys/devices/platform/coretemp.0/.
>>
> That isn't where you are supposed to look for hwmon attributes.
>
>> Now We don't see them. Now we have to go
>> /sys/devices/platform/coretemp.0/hwmon/hwmon?/ to get these values.
>>
> This is also not the correct location.
>
> You should be looking in /sys/class/hwmon/hwmonX/.
>
> There will be a name attribute either in /sys/class/hwmon/hwmonX/name
> or in /sys/class/hwmon/hwmonX/device/name. For coretemp, the value
> reported in the name attribute will be 'coretemp'. This defines the
> directory where the actual sensor attributes will be located.
>
> A better approach might be to use libsensors instead of directly
> accessing attributes.
>
> To give you the background, hwmon attributes are in the process of
> being moved from the parent device to the hwmon device, or from
> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
> as part of an effort to streamline the code and make it more
> consistent and maintainable.
>
> Guenter
>
Thanks for your quick reply.

-Srinivas

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp.0 folder contents changed

[Jean Delvare]

Hi Guenter, Srinivas,

On Mon, 5 May 2014 10:32:31 -0700, Guenter Roeck wrote:
> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
> > for kernel : 3.15.rc3 .
> > 
> > Is there any change in the coretemp? Previously we used to see,
> > tempx data (like temp2_input, temp2_max etc.)
> > /sys/devices/platform/coretemp.0/.
>
> That isn't where you are supposed to look for hwmon attributes.

Actually I used to recommend looking there when people were not using
libsensors (e.g. for pwmconfig / fancontrol or custom scripts.) This
path had the great merit of being stable across reboots, while hwmon
class device numbers are not (or at least they aren't guaranteed to be.)

> (...)
> To give you the background, hwmon attributes are in the process of
> being moved from the parent device to the hwmon device, or from
> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
> as part of an effort to streamline the code and make it more
> consistent and maintainable.

I am just realizing that we are also losing the stability of hardware
device based paths with that move :( I suppose I shouldn't have
bothered adding support for this to fancontrol.

Don't get me wrong, I still believe this is the right move, but I fear
that the question of persistent hwmon device names will resurface every
now and then again. libsensors offers a solution but 1* it lacks
support for pwm attributes and 2* it doesn't help with shell or perl
scripts such as pwmconfig and fancontrol.

-- 
Jean Delvare
SUSE L3 Support

Re: [lm-sensors] coretemp.0 folder contents changed

[Jean Delvare]

Hi Guenter, Srinivas,

On Mon, 5 May 2014 10:32:31 -0700, Guenter Roeck wrote:
> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
> > for kernel : 3.15.rc3 .
> > 
> > Is there any change in the coretemp? Previously we used to see,
> > tempx data (like temp2_input, temp2_max etc.)
> > /sys/devices/platform/coretemp.0/.
>
> That isn't where you are supposed to look for hwmon attributes.

Actually I used to recommend looking there when people were not using
libsensors (e.g. for pwmconfig / fancontrol or custom scripts.) This
path had the great merit of being stable across reboots, while hwmon
class device numbers are not (or at least they aren't guaranteed to be.)

> (...)
> To give you the background, hwmon attributes are in the process of
> being moved from the parent device to the hwmon device, or from
> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
> as part of an effort to streamline the code and make it more
> consistent and maintainable.

I am just realizing that we are also losing the stability of hardware
device based paths with that move :( I suppose I shouldn't have
bothered adding support for this to fancontrol.

Don't get me wrong, I still believe this is the right move, but I fear
that the question of persistent hwmon device names will resurface every
now and then again. libsensors offers a solution but 1* it lacks
support for pwm attributes and 2* it doesn't help with shell or perl
scripts such as pwmconfig and fancontrol.

-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp.0 folder contents changed

[Guenter Roeck]

On 05/06/2014 04:55 AM, Jean Delvare wrote:
> Hi Guenter, Srinivas,
>
> On Mon, 5 May 2014 10:32:31 -0700, Guenter Roeck wrote:
>> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
>>> for kernel : 3.15.rc3 .
>>>
>>> Is there any change in the coretemp? Previously we used to see,
>>> tempx data (like temp2_input, temp2_max etc.)
>>> /sys/devices/platform/coretemp.0/.
>>
>> That isn't where you are supposed to look for hwmon attributes.
>
> Actually I used to recommend looking there when people were not using
> libsensors (e.g. for pwmconfig / fancontrol or custom scripts.) This
> path had the great merit of being stable across reboots, while hwmon
> class device numbers are not (or at least they aren't guaranteed to be.)
>
>> (...)
>> To give you the background, hwmon attributes are in the process of
>> being moved from the parent device to the hwmon device, or from
>> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
>> as part of an effort to streamline the code and make it more
>> consistent and maintainable.
>
> I am just realizing that we are also losing the stability of hardware
> device based paths with that move :( I suppose I shouldn't have
> bothered adding support for this to fancontrol.
>
> Don't get me wrong, I still believe this is the right move, but I fear
> that the question of persistent hwmon device names will resurface every
> now and then again. libsensors offers a solution but 1* it lacks
> support for pwm attributes and 2* it doesn't help with shell or perl
> scripts such as pwmconfig and fancontrol.
>
Can we implement a similar approach to network devices and make hwmon
path names (ie the /sys/class/hwmon/XXX path name) configurable via udev ?
Might be worth exploring.

Guenter

Re: [lm-sensors] coretemp.0 folder contents changed

[Guenter Roeck]

On 05/06/2014 04:55 AM, Jean Delvare wrote:
> Hi Guenter, Srinivas,
>
> On Mon, 5 May 2014 10:32:31 -0700, Guenter Roeck wrote:
>> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
>>> for kernel : 3.15.rc3 .
>>>
>>> Is there any change in the coretemp? Previously we used to see,
>>> tempx data (like temp2_input, temp2_max etc.)
>>> /sys/devices/platform/coretemp.0/.
>>
>> That isn't where you are supposed to look for hwmon attributes.
>
> Actually I used to recommend looking there when people were not using
> libsensors (e.g. for pwmconfig / fancontrol or custom scripts.) This
> path had the great merit of being stable across reboots, while hwmon
> class device numbers are not (or at least they aren't guaranteed to be.)
>
>> (...)
>> To give you the background, hwmon attributes are in the process of
>> being moved from the parent device to the hwmon device, or from
>> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
>> as part of an effort to streamline the code and make it more
>> consistent and maintainable.
>
> I am just realizing that we are also losing the stability of hardware
> device based paths with that move :( I suppose I shouldn't have
> bothered adding support for this to fancontrol.
>
> Don't get me wrong, I still believe this is the right move, but I fear
> that the question of persistent hwmon device names will resurface every
> now and then again. libsensors offers a solution but 1* it lacks
> support for pwm attributes and 2* it doesn't help with shell or perl
> scripts such as pwmconfig and fancontrol.
>
Can we implement a similar approach to network devices and make hwmon
path names (ie the /sys/class/hwmon/XXX path name) configurable via udev ?
Might be worth exploring.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp.0 folder contents changed

[Jean Delvare]

Hi Guenter,

On Tue, 06 May 2014 06:32:15 -0700, Guenter Roeck wrote:
> Can we implement a similar approach to network devices and make hwmon
> path names (ie the /sys/class/hwmon/XXX path name) configurable via udev ?
> Might be worth exploring.

This is one possibility indeed. The good thing is that libsensors makes
no assumption on hwmon class device names, so we can change the names
without breaking any application which uses libsensors. Scripts
accessing sysfs directly may break though (pwmconfig would, for
example.)

We'll have to be careful when choosing the new names, and make sure
there is no name space collision. Network interface renaming has caused
a great deal of trouble out there.

Another approach, which I have in mind for quite some time already but
could never find the time to implement, would be a small helper binary
which would look-up hwmon devices by libsensors-like name (and the
other way around too.) Scripts could use it to benefit from libsensors
persistent names.

-- 
Jean Delvare
SUSE L3 Support

Re: [lm-sensors] coretemp.0 folder contents changed

[Jean Delvare]

Hi Guenter,

On Tue, 06 May 2014 06:32:15 -0700, Guenter Roeck wrote:
> Can we implement a similar approach to network devices and make hwmon
> path names (ie the /sys/class/hwmon/XXX path name) configurable via udev ?
> Might be worth exploring.

This is one possibility indeed. The good thing is that libsensors makes
no assumption on hwmon class device names, so we can change the names
without breaking any application which uses libsensors. Scripts
accessing sysfs directly may break though (pwmconfig would, for
example.)

We'll have to be careful when choosing the new names, and make sure
there is no name space collision. Network interface renaming has caused
a great deal of trouble out there.

Another approach, which I have in mind for quite some time already but
could never find the time to implement, would be a small helper binary
which would look-up hwmon devices by libsensors-like name (and the
other way around too.) Scripts could use it to benefit from libsensors
persistent names.

-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp.0 folder contents changed

[Guenter Roeck]

On 05/07/2014 12:13 AM, Jean Delvare wrote:
> Hi Guenter,
>
> On Tue, 06 May 2014 06:32:15 -0700, Guenter Roeck wrote:
>> Can we implement a similar approach to network devices and make hwmon
>> path names (ie the /sys/class/hwmon/XXX path name) configurable via udev ?
>> Might be worth exploring.
>
> This is one possibility indeed. The good thing is that libsensors makes
> no assumption on hwmon class device names, so we can change the names
> without breaking any application which uses libsensors. Scripts
> accessing sysfs directly may break though (pwmconfig would, for
> example.)
>
> We'll have to be careful when choosing the new names, and make sure
> there is no name space collision. Network interface renaming has caused
> a great deal of trouble out there.
>
Agreed. I'll try to find some time to play with it.

> Another approach, which I have in mind for quite some time already but
> could never find the time to implement, would be a small helper binary
> which would look-up hwmon devices by libsensors-like name (and the
> other way around too.) Scripts could use it to benefit from libsensors
> persistent names.
>
Still needs that binary, though.

Guenter

Re: [lm-sensors] coretemp.0 folder contents changed

[Guenter Roeck]

On 05/07/2014 12:13 AM, Jean Delvare wrote:
> Hi Guenter,
>
> On Tue, 06 May 2014 06:32:15 -0700, Guenter Roeck wrote:
>> Can we implement a similar approach to network devices and make hwmon
>> path names (ie the /sys/class/hwmon/XXX path name) configurable via udev ?
>> Might be worth exploring.
>
> This is one possibility indeed. The good thing is that libsensors makes
> no assumption on hwmon class device names, so we can change the names
> without breaking any application which uses libsensors. Scripts
> accessing sysfs directly may break though (pwmconfig would, for
> example.)
>
> We'll have to be careful when choosing the new names, and make sure
> there is no name space collision. Network interface renaming has caused
> a great deal of trouble out there.
>
Agreed. I'll try to find some time to play with it.

> Another approach, which I have in mind for quite some time already but
> could never find the time to implement, would be a small helper binary
> which would look-up hwmon devices by libsensors-like name (and the
> other way around too.) Scripts could use it to benefit from libsensors
> persistent names.
>
Still needs that binary, though.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp.0 folder contents changed

[Jean Delvare]

Hi Guenter,

On Wed, 07 May 2014 05:10:58 -0700, Guenter Roeck wrote:
> On 05/07/2014 12:13 AM, Jean Delvare wrote:
> > On Tue, 06 May 2014 06:32:15 -0700, Guenter Roeck wrote:
> >> Can we implement a similar approach to network devices and make hwmon
> >> path names (ie the /sys/class/hwmon/XXX path name) configurable via udev ?
> >> Might be worth exploring.
> >
> > This is one possibility indeed. The good thing is that libsensors makes
> > no assumption on hwmon class device names, so we can change the names
> > without breaking any application which uses libsensors. Scripts
> > accessing sysfs directly may break though (pwmconfig would, for
> > example.)
> >
> > We'll have to be careful when choosing the new names, and make sure
> > there is no name space collision. Network interface renaming has caused
> > a great deal of trouble out there.
>
> Agreed. I'll try to find some time to play with it.
> 
> > Another approach, which I have in mind for quite some time already but
> > could never find the time to implement, would be a small helper binary
> > which would look-up hwmon devices by libsensors-like name (and the
> > other way around too.) Scripts could use it to benefit from libsensors
> > persistent names.
>
> Still needs that binary, though.

I have a proof of concept ready, I'll post it in a minute.

-- 
Jean Delvare
SUSE L3 Support

Re: [lm-sensors] coretemp.0 folder contents changed

[Jean Delvare]

Hi Guenter,

On Wed, 07 May 2014 05:10:58 -0700, Guenter Roeck wrote:
> On 05/07/2014 12:13 AM, Jean Delvare wrote:
> > On Tue, 06 May 2014 06:32:15 -0700, Guenter Roeck wrote:
> >> Can we implement a similar approach to network devices and make hwmon
> >> path names (ie the /sys/class/hwmon/XXX path name) configurable via udev ?
> >> Might be worth exploring.
> >
> > This is one possibility indeed. The good thing is that libsensors makes
> > no assumption on hwmon class device names, so we can change the names
> > without breaking any application which uses libsensors. Scripts
> > accessing sysfs directly may break though (pwmconfig would, for
> > example.)
> >
> > We'll have to be careful when choosing the new names, and make sure
> > there is no name space collision. Network interface renaming has caused
> > a great deal of trouble out there.
>
> Agreed. I'll try to find some time to play with it.
> 
> > Another approach, which I have in mind for quite some time already but
> > could never find the time to implement, would be a small helper binary
> > which would look-up hwmon devices by libsensors-like name (and the
> > other way around too.) Scripts could use it to benefit from libsensors
> > persistent names.
>
> Still needs that binary, though.

I have a proof of concept ready, I'll post it in a minute.

-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp.0 folder contents changed

[Srinivas Pandruvada]

On 05/06/2014 04:55 AM, Jean Delvare wrote:
> Hi Guenter, Srinivas,
>
> On Mon, 5 May 2014 10:32:31 -0700, Guenter Roeck wrote:
>> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
>>> for kernel : 3.15.rc3 .
>>>
>>> Is there any change in the coretemp? Previously we used to see,
>>> tempx data (like temp2_input, temp2_max etc.)
>>> /sys/devices/platform/coretemp.0/.
>> That isn't where you are supposed to look for hwmon attributes.
> Actually I used to recommend looking there when people were not using
> libsensors (e.g. for pwmconfig / fancontrol or custom scripts.) This
> path had the great merit of being stable across reboots, while hwmon
> class device numbers are not (or at least they aren't guaranteed to be.)
I maintain thermal daemon, which was using the path. So once Ubuntu 
upgrade kernel,
this will break. So I have to make sure that corresponding user space 
change is submitted.
I don't want to depend on too many libraries as it also runs on many 
embedded platforms
where many library pre-builts don't exists.
>> (...)
>> To give you the background, hwmon attributes are in the process of
>> being moved from the parent device to the hwmon device, or from
>> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
>> as part of an effort to streamline the code and make it more
>> consistent and maintainable.
> I am just realizing that we are also losing the stability of hardware
> device based paths with that move :( I suppose I shouldn't have
> bothered adding support for this to fancontrol.
>
> Don't get me wrong, I still believe this is the right move, but I fear
> that the question of persistent hwmon device names will resurface every
> now and then again. libsensors offers a solution but 1* it lacks
> support for pwm attributes and 2* it doesn't help with shell or perl
> scripts such as pwmconfig and fancontrol.
Also when using Android like platform with limited library support,
we have to make sure that libsensor exists.


Thanks,
Srinivas

Re: [lm-sensors] coretemp.0 folder contents changed

[Srinivas Pandruvada]

On 05/06/2014 04:55 AM, Jean Delvare wrote:
> Hi Guenter, Srinivas,
>
> On Mon, 5 May 2014 10:32:31 -0700, Guenter Roeck wrote:
>> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
>>> for kernel : 3.15.rc3 .
>>>
>>> Is there any change in the coretemp? Previously we used to see,
>>> tempx data (like temp2_input, temp2_max etc.)
>>> /sys/devices/platform/coretemp.0/.
>> That isn't where you are supposed to look for hwmon attributes.
> Actually I used to recommend looking there when people were not using
> libsensors (e.g. for pwmconfig / fancontrol or custom scripts.) This
> path had the great merit of being stable across reboots, while hwmon
> class device numbers are not (or at least they aren't guaranteed to be.)
I maintain thermal daemon, which was using the path. So once Ubuntu 
upgrade kernel,
this will break. So I have to make sure that corresponding user space 
change is submitted.
I don't want to depend on too many libraries as it also runs on many 
embedded platforms
where many library pre-builts don't exists.
>> (...)
>> To give you the background, hwmon attributes are in the process of
>> being moved from the parent device to the hwmon device, or from
>> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
>> as part of an effort to streamline the code and make it more
>> consistent and maintainable.
> I am just realizing that we are also losing the stability of hardware
> device based paths with that move :( I suppose I shouldn't have
> bothered adding support for this to fancontrol.
>
> Don't get me wrong, I still believe this is the right move, but I fear
> that the question of persistent hwmon device names will resurface every
> now and then again. libsensors offers a solution but 1* it lacks
> support for pwm attributes and 2* it doesn't help with shell or perl
> scripts such as pwmconfig and fancontrol.
Also when using Android like platform with limited library support,
we have to make sure that libsensor exists.


Thanks,
Srinivas


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp.0 folder contents changed

[Srinivas Pandruvada]

On 05/06/2014 08:20 AM, Srinivas Pandruvada wrote:
> On 05/06/2014 04:55 AM, Jean Delvare wrote:
>> Hi Guenter, Srinivas,
>>
>> On Mon, 5 May 2014 10:32:31 -0700, Guenter Roeck wrote:
>>> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
>>>> for kernel : 3.15.rc3 .
>>>>
>>>> Is there any change in the coretemp? Previously we used to see,
>>>> tempx data (like temp2_input, temp2_max etc.)
>>>> /sys/devices/platform/coretemp.0/.
>>> That isn't where you are supposed to look for hwmon attributes.
>> Actually I used to recommend looking there when people were not using
>> libsensors (e.g. for pwmconfig / fancontrol or custom scripts.) This
>> path had the great merit of being stable across reboots, while hwmon
>> class device numbers are not (or at least they aren't guaranteed to be.)
> I maintain thermal daemon, which was using the path. So once Ubuntu 
> upgrade kernel,
> this will break. So I have to make sure that corresponding user space 
> change is submitted.
> I don't want to depend on too many libraries as it also runs on many 
> embedded platforms
> where many library pre-builts don't exists.
>>> (...)
>>> To give you the background, hwmon attributes are in the process of
>>> being moved from the parent device to the hwmon device, or from
>>> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
>>> as part of an effort to streamline the code and make it more
>>> consistent and maintainable.
>> I am just realizing that we are also losing the stability of hardware
>> device based paths with that move :( I suppose I shouldn't have
>> bothered adding support for this to fancontrol.
>>
>> Don't get me wrong, I still believe this is the right move, but I fear
>> that the question of persistent hwmon device names will resurface every
>> now and then again. libsensors offers a solution but 1* it lacks
>> support for pwm attributes and 2* it doesn't help with shell or perl
>> scripts such as pwmconfig and fancontrol.
> Also when using Android like platform with limited library support,
> we have to make sure that libsensor exists.
>
>
Also some documents which can be downloaded from intel.com, refers to 
this path.
http://www.intel.com/content/www/us/en/intelligent-systems/cpu-monitoring-dts-peci-paper.html
So we need to request document owners to update path. But it is possible 
that OEM/ODMs also
has similar documents or refer to such documentation.

> Thanks,
> Srinivas
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

Re: [lm-sensors] coretemp.0 folder contents changed

[Srinivas Pandruvada]

On 05/06/2014 08:20 AM, Srinivas Pandruvada wrote:
> On 05/06/2014 04:55 AM, Jean Delvare wrote:
>> Hi Guenter, Srinivas,
>>
>> On Mon, 5 May 2014 10:32:31 -0700, Guenter Roeck wrote:
>>> On Mon, May 05, 2014 at 10:13:11AM -0700, Srinivas Pandruvada wrote:
>>>> for kernel : 3.15.rc3 .
>>>>
>>>> Is there any change in the coretemp? Previously we used to see,
>>>> tempx data (like temp2_input, temp2_max etc.)
>>>> /sys/devices/platform/coretemp.0/.
>>> That isn't where you are supposed to look for hwmon attributes.
>> Actually I used to recommend looking there when people were not using
>> libsensors (e.g. for pwmconfig / fancontrol or custom scripts.) This
>> path had the great merit of being stable across reboots, while hwmon
>> class device numbers are not (or at least they aren't guaranteed to be.)
> I maintain thermal daemon, which was using the path. So once Ubuntu 
> upgrade kernel,
> this will break. So I have to make sure that corresponding user space 
> change is submitted.
> I don't want to depend on too many libraries as it also runs on many 
> embedded platforms
> where many library pre-builts don't exists.
>>> (...)
>>> To give you the background, hwmon attributes are in the process of
>>> being moved from the parent device to the hwmon device, or from
>>> /sys/class/hwmon/hwmonX/device/ to /sys/class/hwmon/hwmonX/,
>>> as part of an effort to streamline the code and make it more
>>> consistent and maintainable.
>> I am just realizing that we are also losing the stability of hardware
>> device based paths with that move :( I suppose I shouldn't have
>> bothered adding support for this to fancontrol.
>>
>> Don't get me wrong, I still believe this is the right move, but I fear
>> that the question of persistent hwmon device names will resurface every
>> now and then again. libsensors offers a solution but 1* it lacks
>> support for pwm attributes and 2* it doesn't help with shell or perl
>> scripts such as pwmconfig and fancontrol.
> Also when using Android like platform with limited library support,
> we have to make sure that libsensor exists.
>
>
Also some documents which can be downloaded from intel.com, refers to 
this path.
http://www.intel.com/content/www/us/en/intelligent-systems/cpu-monitoring-dts-peci-paper.html
So we need to request document owners to update path. But it is possible 
that OEM/ODMs also
has similar documents or refer to such documentation.

> Thanks,
> Srinivas
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp.0 folder contents changed

[Jean Delvare]

On Tue, 06 May 2014 08:20:22 -0700, Srinivas Pandruvada wrote:
> I maintain thermal daemon, which was using the path. So once Ubuntu 
> upgrade kernel,
> this will break. So I have to make sure that corresponding user space 
> change is submitted.
> I don't want to depend on too many libraries as it also runs on many 
> embedded platforms
> where many library pre-builts don't exists.
> (...)
> Also when using Android like platform with limited library support,
> we have to make sure that libsensor exists.

libsensors is small, fast and portable. There's really no excuse for
not using it if your daemon is written in C or C++.

-- 
Jean Delvare
SUSE L3 Support

Re: [lm-sensors] coretemp.0 folder contents changed

[Jean Delvare]

On Tue, 06 May 2014 08:20:22 -0700, Srinivas Pandruvada wrote:
> I maintain thermal daemon, which was using the path. So once Ubuntu 
> upgrade kernel,
> this will break. So I have to make sure that corresponding user space 
> change is submitted.
> I don't want to depend on too many libraries as it also runs on many 
> embedded platforms
> where many library pre-builts don't exists.
> (...)
> Also when using Android like platform with limited library support,
> we have to make sure that libsensor exists.

libsensors is small, fast and portable. There's really no excuse for
not using it if your daemon is written in C or C++.

-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors