Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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-sens...@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] coretemp.0 folder contents changed
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-sens...@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
