[lm-sensors] Updated initialization script, testers wanted

[lm-sensors] Updated initialization script, testers wanted

[Jean Delvare]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

Hi Hans,

I have implemented and committed the sensors-detect side of ticket
#2246. Now the lm_sensors initialization script needs to be updated as
well, to make use of the new configuration file syntax. The
initialization script in our repository is meant for Red Hat
distributions but I don't have any, so I can't test my changes. The
patch I intend to apply is attached, could you (or anyone with a Red
Hat distribution) give it a try and confirm that it works OK?
Beforehand, you'll need to download and run the latest version of
sensors-detect:

http://www.lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0/prog/detect/sensors-detect

and let it regenerate /etc/sysconfig/lm_sensors.

Thanks,
-- 
Jean Delvare

[-- Attachment #2: init-new-format.patch --]
[-- Type: text/x-patch, Size: 2003 bytes --]

Update the initialization script to make use of the new syntax
of /etc/sysconfig/lm_sensors.

---
 prog/init/lm_sensors.init |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

--- lm-sensors-3.orig/prog/init/lm_sensors.init	2009-01-12 13:20:39.000000000 +0100
+++ lm-sensors-3/prog/init/lm_sensors.init	2009-01-12 13:47:07.000000000 +0100
@@ -25,9 +25,9 @@
 # It uses a config file /etc/sysconfig/lm_sensors that contains the modules
 # to be loaded/unloaded. That file is sourced into this one.
 
-# The format of that file a shell script that simply defines the modules 
-# in order as normal shell variables with the special names:
-#    MODULE_1, MODULE_2, MODULE_3, etc.
+# The format of this file is a shell script that simply defines variables:
+# HWMON_MODULES for hardware monitoring driver modules, and optionally
+# BUS_MODULES for any required bus driver module (for example for I2C or SPI).
 
 PSENSORS=/usr/local/bin/sensors
 
@@ -68,7 +68,7 @@ check_sensors() {
 	fi
 
 	CONFIG=/etc/sysconfig/lm_sensors
-	if ! [ -r "$CONFIG" ] || ! grep '^MODULE_' $CONFIG >/dev/null 2>&1; then
+	if ! [ -r "$CONFIG" ] || ! grep '^HWMON_MODULES' $CONFIG >/dev/null 2>&1; then
 		echo -n "$1 $prog: not configured, run sensors-detect"
 		echo_warning
 		echo
@@ -84,13 +84,9 @@ start() {
 
 	echo -n "Starting $prog: loading module "
 
-	modules=`grep \^MODULE_ $CONFIG | wc -l | tr -d ' '`
-	i=0
-	while [ $i -lt $modules ] ; do
-		module=`eval echo '$'MODULE_$i`
+	for $module in $BUS_MODULES $HWMON_MODULES ; do
 		echo -n "${module} "
 		/sbin/modprobe $module >/dev/null 2>&1
-		i=`expr $i + 1`
 	done
 	$PSENSORS -s
 
@@ -109,12 +105,8 @@ stop() {
 
 	echo -n "Stopping $prog: "
 
-	modules=`grep \^MODULE_ $CONFIG | wc -l | tr -d ' '`
-	i=`expr $modules`
-	while [ $i -ge 0 ] ; do
-		module=`eval echo '$'MODULE_$i`
+	for $module in $HWMON_MODULES $BUS_MODULES ; do
 		/sbin/modprobe -r $module >/dev/null 2>&1
-		i=`expr $i - 1`
 	done
 
 	if [ $WITHSYS == "0" ]; then

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] Updated initialization script, testers wanted

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> I have implemented and committed the sensors-detect side of ticket
> #2246. Now the lm_sensors initialization script needs to be updated as
> well, to make use of the new configuration file syntax. The
> initialization script in our repository is meant for Red Hat
> distributions but I don't have any, so I can't test my changes. The
> patch I intend to apply is attached, could you (or anyone with a Red
> Hat distribution) give it a try and confirm that it works OK?
> Beforehand, you'll need to download and run the latest version of
> sensors-detect:
> 
> http://www.lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0/prog/detect/sensors-detect
> 
> and let it regenerate /etc/sysconfig/lm_sensors.
> 

Erm,

Not tested, I'm not so happy with this change. I've read the ticker trying to 
find out why we would want this change, and I must say I'm not very convinced 
with the reasoning there.

My problem with these changes is that to me it feels like changing the config 
file format without some very strong reasons, this will cause all kind of pains 
when upgrading from an lm_sensors version with the old format to that with the 
new format. Do we really have to do this?

Regards,

Hans

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

Re: [lm-sensors] Updated initialization script, testers wanted

[Jean Delvare]

Hi Hans,

On Tue, 13 Jan 2009 09:02:33 +0100, Hans de Goede wrote:
> Jean Delvare wrote:
> > I have implemented and committed the sensors-detect side of ticket
> > #2246. Now the lm_sensors initialization script needs to be updated as
> > well, to make use of the new configuration file syntax. The
> > initialization script in our repository is meant for Red Hat
> > distributions but I don't have any, so I can't test my changes. The
> > patch I intend to apply is attached, could you (or anyone with a Red
> > Hat distribution) give it a try and confirm that it works OK?
> > Beforehand, you'll need to download and run the latest version of
> > sensors-detect:
> > 
> > http://www.lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0/prog/detect/sensors-detect
> > 
> > and let it regenerate /etc/sysconfig/lm_sensors.
> 
> Erm,
> 
> Not tested, I'm not so happy with this change. I've read the ticker trying to 
> find out why we would want this change, and I must say I'm not very convinced 
> with the reasoning there.
> 
> My problem with these changes is that to me it feels like changing the config 
> file format without some very strong reasons, this will cause all kind of pains 
> when upgrading from an lm_sensors version with the old format to that with the 
> new format. Do we really have to do this?

The two reasons that motivated the change are explained in the ticket,
there's not so much I can add:

1* Removing or adding a module manually is error-prone. Say you have
the following configuration file:

MODULE_0=lm90
MODULE_1=k8temp
MODULE_2=it87

Now you change your graphics adapter and the new one no longer has a
thermal sensor, so you no longer need to load the lm90 driver. Simply
removing the first line may or may not be enough, depending on how the
initialization script is implemented. Apparently the one in openSUSE
copes with that, but the one in our repository (which I think you use
in Red Hat) doesn't.

2* The old format can't be edited with Yast's sysconfig editor, as the
editor expects fixed variable names. I find it pretty convenient for
the user to be able to edit all the system settings in a central place,
with settings put in a function-oriented tree, and a help text for every
setting. I don't know if Red Hat has an equivalent tool, but if it does
then I expect it to have the same problem with the current lm-sensors
configuration file format. It is much easier for me to tell a user to
open the sysconfig editor and change the value of variable
HWMON_MODULES to "foo bar" than to tell him/her to
open /etc/sysconfig/lm_sensors with a text editor, check the highest
MODULE_%d variable, and add a new line MODULE_%(d+1)ºr.

On top of that, you can see that the code to generate and read the new
format is more simple. And the new format is clearer for the reader, as
it distinguishes between bus drivers and actual hardware monitoring
drivers.

I agree that there is a migration path issue when changing the format.
But it doesn't seem blocking to me. The changes I made to
sensors-detect are such that both formats will be generated for the
time being, and we can keep things that way for several releases. Each
distribution is free to switch to the new format as they see fit. If
you don't want to upgrade it now in Red Hat, just don't.

I am open to suggestions to make the migration path easier. I could
write a small shell script to convert from the old format to the new
one. This could become part of the post-install script of new
lm-sensors packages (RPM or other) so that upgrades work transparently
for the user. Would the change then be acceptable to you?

-- 
Jean Delvare

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

Re: [lm-sensors] Updated initialization script, testers wanted

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Tue, 13 Jan 2009 09:02:33 +0100, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> I have implemented and committed the sensors-detect side of ticket
>>> #2246. Now the lm_sensors initialization script needs to be updated as
>>> well, to make use of the new configuration file syntax. The
>>> initialization script in our repository is meant for Red Hat
>>> distributions but I don't have any, so I can't test my changes. The
>>> patch I intend to apply is attached, could you (or anyone with a Red
>>> Hat distribution) give it a try and confirm that it works OK?
>>> Beforehand, you'll need to download and run the latest version of
>>> sensors-detect:
>>>
>>> http://www.lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0/prog/detect/sensors-detect
>>>
>>> and let it regenerate /etc/sysconfig/lm_sensors.
>> Erm,
>>
>> Not tested, I'm not so happy with this change. I've read the ticker trying to 
>> find out why we would want this change, and I must say I'm not very convinced 
>> with the reasoning there.
>>
>> My problem with these changes is that to me it feels like changing the config 
>> file format without some very strong reasons, this will cause all kind of pains 
>> when upgrading from an lm_sensors version with the old format to that with the 
>> new format. Do we really have to do this?
> 
> The two reasons that motivated the change are explained in the ticket,
> there's not so much I can add:
> 
> 1* Removing or adding a module manually is error-prone. Say you have
> the following configuration file:
> 
> MODULE_0=lm90
> MODULE_1=k8temp
> MODULE_2=it87
> 
> Now you change your graphics adapter and the new one no longer has a
> thermal sensor, so you no longer need to load the lm90 driver. Simply
> removing the first line may or may not be enough, depending on how the
> initialization script is implemented. Apparently the one in openSUSE
> copes with that, but the one in our repository (which I think you use
> in Red Hat) doesn't.
> 
> 2* The old format can't be edited with Yast's sysconfig editor, as the
> editor expects fixed variable names. I find it pretty convenient for
> the user to be able to edit all the system settings in a central place,
> with settings put in a function-oriented tree, and a help text for every
> setting. I don't know if Red Hat has an equivalent tool, but if it does
> then I expect it to have the same problem with the current lm-sensors
> configuration file format. It is much easier for me to tell a user to
> open the sysconfig editor and change the value of variable
> HWMON_MODULES to "foo bar" than to tell him/her to
> open /etc/sysconfig/lm_sensors with a text editor, check the highest
> MODULE_%d variable, and add a new line MODULE_%(d+1)ºr.
> 

Hmm, 1 is sort of silly IMHO if you are making changes renumbering really isn't 
that hard to do, 2 to me feels like causing pain for all distros for the 
benefit of one.

Anyways if we are going to make changes to the format, yes we will need a 
migration script and, I think we need to think this through more.

To be more specific in the future we might / will hopefully get support for 
hwmon on graphics cards, then hopefully everything needed will autoload but we 
might need entries in /etc/sysconfig/lm_sensors, so I'm thinking that it would 
be good to have separate lines for things like motherboard sensors, gpu sensors 
and harddisk sensors. This will make it easier for both manual editing as for 
tools for (automatic) configuration.

Regards,

Hans

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

Re: [lm-sensors] Updated initialization script, testers wanted

[Jean Delvare]

Hi Hans,

On Tue, 13 Jan 2009 19:45:58 +0100, Hans de Goede wrote:
> Jean Delvare wrote:
> > The two reasons that motivated the change are explained in the ticket,
> > there's not so much I can add:
> > 
> > 1* Removing or adding a module manually is error-prone. Say you have
> > the following configuration file:
> > 
> > MODULE_0=lm90
> > MODULE_1=k8temp
> > MODULE_2=it87
> > 
> > Now you change your graphics adapter and the new one no longer has a
> > thermal sensor, so you no longer need to load the lm90 driver. Simply
> > removing the first line may or may not be enough, depending on how the
> > initialization script is implemented. Apparently the one in openSUSE
> > copes with that, but the one in our repository (which I think you use
> > in Red Hat) doesn't.
> > 
> > 2* The old format can't be edited with Yast's sysconfig editor, as the
> > editor expects fixed variable names. I find it pretty convenient for
> > the user to be able to edit all the system settings in a central place,
> > with settings put in a function-oriented tree, and a help text for every
> > setting. I don't know if Red Hat has an equivalent tool, but if it does
> > then I expect it to have the same problem with the current lm-sensors
> > configuration file format. It is much easier for me to tell a user to
> > open the sysconfig editor and change the value of variable
> > HWMON_MODULES to "foo bar" than to tell him/her to
> > open /etc/sysconfig/lm_sensors with a text editor, check the highest
> > MODULE_%d variable, and add a new line MODULE_%(d+1)ºr.
> 
> Hmm, 1 is sort of silly IMHO if you are making changes renumbering really isn't 
> that hard to do,

For me and you, it is easy. For the average user, not necessarily.
Remember, this change was motivated by my experience with openSuse user
support, essentially over bugzilla. This isn't the same category of
users as those asking for help on our mailing list after they have
self-compiled lm-sensors.

> 2 to me feels like causing pain for all distros for the 
> benefit of one.

Frankly I don't see this change as a major pain. If I thought it did, I
wouldn't be proposing it. Converting the configuration file from the
old to the new format is done by 19 lines of shell:

CONFIG=/etc/sysconfig/lm_sensors
test -r "$CONFIG" || exit

unset ${!MODULE_*} $HWMON_MODULES
. "$CONFIG"
test -n "$HWMON_MODULES" && exit

for i in ${!MODULE_*} ; do
	eval module=\$$i
	if test -z "$HWMON_MODULES" ; then
		HWMON_MODULES="$module"
	else
		HWMON_MODULES="$HWMON_MODULES $module"
	fi
done

echo >> "$CONFIG"
echo "# New configuration format generated by sysconfig-lm_sensors-convert" >> "$CONFIG"
echo "HWMON_MODULES=\"$HWMON_MODULES\"" >> "$CONFIG"

(Yes, I kept it voluntarily simple, so bus drivers end up in
HWMON_MODULES, but that's not a problem in practice.)

I also don't think Suse is the only distribution which would benefit
from the change. The fact that the new format is easier to parse than
the original format is an objective fact, it doesn't depend on the
distribution. For example, right now Debian is adding the modules to
load to /etc/modules, which isn't too convenient because you can't
automatically remove entries from that file (if sensors-detect is
re-run you may end up with duplicate entries.) I don't know why they do
that but I can imagine that our configuration file format didn't please
them and they went for the most immediate alternative.

With the new format, Debian could have a new configuration
file /etc/default/lm_sensors similar to /etc/sysconfig/lm_sensors on
Red Hat and Suse distributions. Maybe Aurelien wants to comment on this?

If everybody hates my idea then I am not going to push it to you. I
could implement things my way in Suse and leave the rest of you alone.
But I also think there is a benefit in having a similar configuration
mechanism across major distributions.

> Anyways if we are going to make changes to the format, yes we will need a 
> migration script and, I think we need to think this through more.
> 
> To be more specific in the future we might / will hopefully get support for 
> hwmon on graphics cards,

We already do to some extent, but there's definitely room for
improvement.

> (...) then hopefully everything needed will autoload

Really? I agree for bus drivers, but this seems difficult for hwmon
chip drivers. Do you have some ideas that you didn't share with us yet?

> (...) but we 
> might need entries in /etc/sysconfig/lm_sensors, so I'm thinking that it would 
> be good to have separate lines for things like motherboard sensors, gpu sensors 
> and harddisk sensors. This will make it easier for both manual editing as for 
> tools for (automatic) configuration.

My initial goal was to make the configuration file more simple, not
more complex ;) The main reason why I wanted to split bus drivers and
hardware monitoring chip drivers is that lm_sensors should be
considered not configured as long as no hardware monitoring drivers are
listed. The fact that this will make things a little clearer to the
users is only a side benefit. Oh, and in a few cases, it is more
efficient to load the bus drivers first.

I don't see much value in splitting the variables further.

Bus drivers will almost always auto-load these days, so these variables
will almost always be empty. And the trend for graphics adapter is to
expose I2C buses from the graphics driver itself, so you aren't loading
the bus drivers just for lm-sensors.

If we ever have a kernel driver for hard disk temperatures (that would
be nice!) then I suspect it will be the same driver for all disks, and
hopefully it will auto-load.

This leaves us with the hardware monitoring chips themselves. Given
that it is possible that the same driver is used for the motherboard
and for the graphics adapter, how would you split them? Sure, you could
list the module twice, but that's not exactly efficient.

What benefits do you see in splitting the variables that way?

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] Updated initialization script, testers wanted

[Volker Kuhlmann]

On Wed 14 Jan 2009 07:45:58 NZDT +1300, Hans de Goede wrote:

> 2 to me feels like causing pain for all distros for the 
> benefit of one.

With this attitude you'll never make user-friendly software. Worse,
you're at most aiming at average. Wouldn't it be better to support those
distro(s?) which have advanced to a technological stage of having a
centralised user-managable system admin tool, so the support is in place
when the trailing distros catch up?

Greets,

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.

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

Re: [lm-sensors] Updated initialization script, testers wanted

[Hans de Goede]

Jean Delvare wrote:

<snip>

> 
> Frankly I don't see this change as a major pain. If I thought it did, I
> wouldn't be proposing it. Converting the configuration file from the
> old to the new format is done by 19 lines of shell:
> 
> CONFIG=/etc/sysconfig/lm_sensors
> test -r "$CONFIG" || exit
> 
> unset ${!MODULE_*} $HWMON_MODULES
> . "$CONFIG"
> test -n "$HWMON_MODULES" && exit
> 
> for i in ${!MODULE_*} ; do
> 	eval module=\$$i
> 	if test -z "$HWMON_MODULES" ; then
> 		HWMON_MODULES="$module"
> 	else
> 		HWMON_MODULES="$HWMON_MODULES $module"
> 	fi
> done
> 
> echo >> "$CONFIG"
> echo "# New configuration format generated by sysconfig-lm_sensors-convert" >> "$CONFIG"
> echo "HWMON_MODULES=\"$HWMON_MODULES\"" >> "$CONFIG"
> 
> (Yes, I kept it voluntarily simple, so bus drivers end up in
> HWMON_MODULES, but that's not a problem in practice.)
> 

Ok, as discussed on IRC I'll give up my resistance against this change. If you 
really want to change this I can live with it.

>> Anyways if we are going to make changes to the format, yes we will need a 
>> migration script and, I think we need to think this through more.
>>
>> To be more specific in the future we might / will hopefully get support for 
>> hwmon on graphics cards,
> 
> We already do to some extent, but there's definitely room for
> improvement.
> 
>> (...) then hopefully everything needed will autoload
> 
> Really? I agree for bus drivers, but this seems difficult for hwmon
> chip drivers. Do you have some ideas that you didn't share with us yet?
> 

Well I hope that for graphiccards, the drm / modesetting driver will also 
(probe for?) and instantiate any known to be (sometimes) present i2c sensors.

>> (...) but we 
>> might need entries in /etc/sysconfig/lm_sensors, so I'm thinking that it would 
>> be good to have separate lines for things like motherboard sensors, gpu sensors 
>> and harddisk sensors. This will make it easier for both manual editing as for 
>> tools for (automatic) configuration.
> 
> My initial goal was to make the configuration file more simple, not
> more complex ;) The main reason why I wanted to split bus drivers and
> hardware monitoring chip drivers is that lm_sensors should be
> considered not configured as long as no hardware monitoring drivers are
> listed. The fact that this will make things a little clearer to the
> users is only a side benefit. Oh, and in a few cases, it is more
> efficient to load the bus drivers first.
> 
> I don't see much value in splitting the variables further.
> 
> Bus drivers will almost always auto-load these days, so these variables
> will almost always be empty. And the trend for graphics adapter is to
> expose I2C buses from the graphics driver itself, so you aren't loading
> the bus drivers just for lm-sensors.
> 
> If we ever have a kernel driver for hard disk temperatures (that would
> be nice!) then I suspect it will be the same driver for all disks, and
> hopefully it will auto-load.
> 
> This leaves us with the hardware monitoring chips themselves. Given
> that it is possible that the same driver is used for the motherboard
> and for the graphics adapter, how would you split them? Sure, you could
> list the module twice, but that's not exactly efficient.
> 
> What benefits do you see in splitting the variables that way?
> 

Oneday I hope we have a tool which will generate and /etc/sensors.conf and 
/etc/sysconfig/lm_sensors based on dmi info and a database, then it would be 
good to have separate line in /etc/sysconfig/lm_sensors, for sensors located on 
the motherboard and sensors located on for example a graphic card, so that that 
tool then can only mangle the motherboard lines, without touching any 
(potentially manually added) other line.

Anyways I've tested your init scripts modifications, and there is one bug, the 
line:
        for $module in $BUS_MODULES $HWMON_MODULES ; do

Should be
        for module in $BUS_MODULES $HWMON_MODULES ; do

IOW $module -> module, this needs to be fixed in *2* places.

Regards,

Hans


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

Re: [lm-sensors] Updated initialization script, testers wanted

[Jean Delvare]

Hi Hans,

On Sun, 25 Jan 2009 14:47:30 +0100, Hans de Goede wrote:
> Jean Delvare wrote:
> > Really? I agree for bus drivers, but this seems difficult for hwmon
> > chip drivers. Do you have some ideas that you didn't share with us yet?
> 
> Well I hope that for graphiccards, the drm / modesetting driver will also 
> (probe for?) and instantiate any known to be (sometimes) present i2c sensors.

If they are going to do the same probings we have to do for mainboards,
then I don't quite get the point. Unless we move the probing to the
kernel for mainboards as well, but then that basically means moving
sensors-detect as a whole into the kernel. This is not a trivial thing.
OTOH this would solve the whole user-space problem, letting us get rid
of both sensors-detect and most of the lm_sensors script.

If it is possible to instantiate the sensor devices without probing
because you can get enough information from the hardware to know what
and where they are, then that's a different story, and I agree we
should do that. Any probing we can avoid is good.

> > My initial goal was to make the configuration file more simple, not
> > more complex ;) The main reason why I wanted to split bus drivers and
> > hardware monitoring chip drivers is that lm_sensors should be
> > considered not configured as long as no hardware monitoring drivers are
> > listed. The fact that this will make things a little clearer to the
> > users is only a side benefit. Oh, and in a few cases, it is more
> > efficient to load the bus drivers first.
> > 
> > I don't see much value in splitting the variables further.
> > 
> > Bus drivers will almost always auto-load these days, so these variables
> > will almost always be empty. And the trend for graphics adapter is to
> > expose I2C buses from the graphics driver itself, so you aren't loading
> > the bus drivers just for lm-sensors.
> > 
> > If we ever have a kernel driver for hard disk temperatures (that would
> > be nice!) then I suspect it will be the same driver for all disks, and
> > hopefully it will auto-load.
> > 
> > This leaves us with the hardware monitoring chips themselves. Given
> > that it is possible that the same driver is used for the motherboard
> > and for the graphics adapter, how would you split them? Sure, you could
> > list the module twice, but that's not exactly efficient.
> > 
> > What benefits do you see in splitting the variables that way?
> 
> Oneday I hope we have a tool which will generate and /etc/sensors.conf and 
> /etc/sysconfig/lm_sensors based on dmi info and a database, then it would be 
> good to have separate line in /etc/sysconfig/lm_sensors, for sensors located on 
> the motherboard and sensors located on for example a graphic card, so that that 
> tool then can only mangle the motherboard lines, without touching any 
> (potentially manually added) other line.

I don't expect /etc/sensors.conf to be ever generated. Instead my plan
is to change libsensors to read all configuration files from
directory /etc/sensors.d. Then our to-be-written configuration tool
would simply drop board-specific configuration files to that directory.
This is IMHO much easier than merging several files
into /etc/sensors.conf. I wanted to work on this before the end of
January but have been delayed by other issues.

With regards to separate variables in /etc/sysconfig/lm_sensors, it
seems to only make sense if our to-be-written configuration tool allows
the user to reconfigure the sensors separately on the mainboard and on
graphics adapters. Do we have a need for this? At the moment,
sensors-detect doesn't make any difference between the mainboard and
graphics adapters, it probes the graphics adapters' I2C buses as it
does for the SMBus.

Manually added drivers are a different thing, and there I agree that a
separate variable makes some sense so that automatic reconfiguration
doesn't affect the personal settings. We could have a variable
EXTRA_MODULES for that. That being said, right now sensors-detect
doesn't modify /etc/sysconfig/lm_sensors: it overwrites it. So no
matter what extra variables we have, they will be lost each time
sensors-detect is run. I have created ticket #2369 for this.

But I don't think there is anything that needs to be done now. The new
configuration file format is easily extended in the future if we need
variables for specific purposes.

> Anyways I've tested your init scripts modifications, and there is one bug, the 
> line:
>         for $module in $BUS_MODULES $HWMON_MODULES ; do
> 
> Should be
>         for module in $BUS_MODULES $HWMON_MODULES ; do
> 
> IOW $module -> module, this needs to be fixed in *2* places.

Oops, sorry, I had fixed this one locally but apparently sent the
broken patch on the list. Thanks for reporting.

I'll commit the fixed patch now, together with the small conversion
script to make distribution integration easier.

-- 
Jean Delvare

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

Re: [lm-sensors] Updated initialization script, testers wanted

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Sun, 25 Jan 2009 14:47:30 +0100, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> Really? I agree for bus drivers, but this seems difficult for hwmon
>>> chip drivers. Do you have some ideas that you didn't share with us yet?
>> Well I hope that for graphiccards, the drm / modesetting driver will also 
>> (probe for?) and instantiate any known to be (sometimes) present i2c sensors.
> 
> If they are going to do the same probings we have to do for mainboards,
> then I don't quite get the point.

Well yes and no, most cards based on a certain GPU all use the same hwmon IC 
(the one from the reference design). But some may deviate, so there only needs 
to be a probe for one, maybe 2 chips, and a fairly simple probe. There is no 
certainty that some manufacturer won't deviate, hence the probe is needed, but 
the situation is nowhere as bad as with mainboards.

> If it is possible to instantiate the sensor devices without probing
> because you can get enough information from the hardware to know what
> and where they are, then that's a different story, and I agree we
> should do that. Any probing we can avoid is good.
> 

Well there is no 100% certainty (AFAIK) so we still need a probe, but basicly 
only for one chip, if the user has one of the rare deviating board he / she is 
out of luck.

>>> My initial goal was to make the configuration file more simple, not
>>> more complex ;) The main reason why I wanted to split bus drivers and
>>> hardware monitoring chip drivers is that lm_sensors should be
>>> considered not configured as long as no hardware monitoring drivers are
>>> listed. The fact that this will make things a little clearer to the
>>> users is only a side benefit. Oh, and in a few cases, it is more
>>> efficient to load the bus drivers first.
>>>
>>> I don't see much value in splitting the variables further.
>>>
>>> Bus drivers will almost always auto-load these days, so these variables
>>> will almost always be empty. And the trend for graphics adapter is to
>>> expose I2C buses from the graphics driver itself, so you aren't loading
>>> the bus drivers just for lm-sensors.
>>>
>>> If we ever have a kernel driver for hard disk temperatures (that would
>>> be nice!) then I suspect it will be the same driver for all disks, and
>>> hopefully it will auto-load.
>>>
>>> This leaves us with the hardware monitoring chips themselves. Given
>>> that it is possible that the same driver is used for the motherboard
>>> and for the graphics adapter, how would you split them? Sure, you could
>>> list the module twice, but that's not exactly efficient.
>>>
>>> What benefits do you see in splitting the variables that way?
>> Oneday I hope we have a tool which will generate and /etc/sensors.conf and 
>> /etc/sysconfig/lm_sensors based on dmi info and a database, then it would be 
>> good to have separate line in /etc/sysconfig/lm_sensors, for sensors located on 
>> the motherboard and sensors located on for example a graphic card, so that that 
>> tool then can only mangle the motherboard lines, without touching any 
>> (potentially manually added) other line.
> 
> I don't expect /etc/sensors.conf to be ever generated. Instead my plan
> is to change libsensors to read all configuration files from
> directory /etc/sensors.d. Then our to-be-written configuration tool
> would simply drop board-specific configuration files to that directory.
> This is IMHO much easier than merging several files
> into /etc/sensors.conf.

Ack, this sounds like a good plan.

> I wanted to work on this before the end of
> January but have been delayed by other issues.
> 
> With regards to separate variables in /etc/sysconfig/lm_sensors, it
> seems to only make sense if our to-be-written configuration tool allows
> the user to reconfigure the sensors separately on the mainboard and on
> graphics adapters. Do we have a need for this? At the moment,
> sensors-detect doesn't make any difference between the mainboard and
> graphics adapters, it probes the graphics adapters' I2C buses as it
> does for the SMBus.

True, I guess this is something best revisited when it actually becomes an issue.

<snip>

> 
> But I don't think there is anything that needs to be done now. The new
> configuration file format is easily extended in the future if we need
> variables for specific purposes.
> 

Ack.


Regards,

Hans

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