[lm-sensors] Updated initialization script, testers wanted
khali at linux-fr.org
Mon Jan 26 15:24:07 CET 2009
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
> 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.
More information about the lm-sensors