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)=bar.
>
> 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
