[lm-sensors] Future plans for sensors-detect

[lm-sensors] Future plans for sensors-detect

[Jean Delvare]

Hi all,

As discussed before the 3.0.2 release, I have plans to change
sensors-detect significantly. As I do not want these changes to affect
the users of 2.10.x legacy tree, this means that we are no longer
trying to keep sensors-detect in sync between both branches. This
doesn't mean that it's forbidden to add detection for new devices in
the 2.10.x one if you want - but keeping both copies as identical as
possible is no longer the goal.

Here is a random and incomplete list of things I have in mind. It will
take some time before I can implement everything, and maybe some points
will not be implemented in the end if they don't seem to be needed or I
don't have the time to implement them.

* Drop Linux 2.4 support. lm-sensors 3.0.x only supports Linux 2.6, so
  if we no longer keep sensors-detect versions in sync, there's no point
  in supporting 2.4 kernels in the lm-sensors 3.0.x one. This will make
  the script somewhat smaller and simpler.

* Revert the order of the probes. This it ticket #2322:
  http://www.lm-sensors.org/ticket/2322
  The idea is to start with the less risky probes, and stop by default
  when we think we have found what we were looking for. The user will
  still be able to continue with the detection if he/she wants.

* SMBus read cache. I submitted something already over one year ago:
  http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018749.html
  But nobody reacted so I never committed my work. The speedup
  generated by this patch alone seemed worth the extra code. Another
  reason now is that limiting the hardware access to these devices
  seems to be a good idea in the light of recent reports we had about
  I2C/SMBus chips reacting to probes in odd ways. The most important
  protection measures have been implemented in 3.0.2 already, but I
  believe that caching the register reads in sensors-detect would
  further prevent the possibility to break something accidentally.

* Get the bus driver names from the kernel. The Linux 2.6 kernel tells
  you which kernel module provides support for a given driver, so we can
  stop guessing it with tricky regexp matching against the i2c bus
  names.

* Fix the bus numbering prediction magic. There's some old code to
  attempt to figure out how I2C bus will be numbered after next reboot,
  so that the "ignore" module options are correct. This code is broken
  in more than one way. It assumes that it knows about all drivers which
  create i2c buses, which is not true (all graphics and multimedia
  adapters in particular are missing.) It assumes that the user will
  reboot after running sensors-detect. It assumes that i2c bus drivers
  don't autoload, while they almost all do by now. And it assumes that
  the bus numbering is stable over reboot, which is not necessarily the
  case (I can't think of a fix for this one though.)

* DMI integration. This is needed for automatic configuration file
  download, and could also be welcome to explicitly skip some probes
  on selected motherboards. Recent kernels export the DMI data so we
  should not even need to depend on dmidecode. Either way I don't want
  to add a hard dependency for DMI, so if it's there we use it, if not
  we'll just do as before.

* Unload i2c-dev at the end of the probe if we loaded it ourselves?

That's all I can think about at the moment but there is certainly more.
I would welcome comments on any of the points above.

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] Future plans for sensors-detect

[Hans de Goede]

Jean Delvare wrote:
> Hi all,
> 
> As discussed before the 3.0.2 release, I have plans to change
> sensors-detect significantly. As I do not want these changes to affect
> the users of 2.10.x legacy tree, this means that we are no longer
> trying to keep sensors-detect in sync between both branches. This
> doesn't mean that it's forbidden to add detection for new devices in
> the 2.10.x one if you want - but keeping both copies as identical as
> possible is no longer the goal.
> 
> Here is a random and incomplete list of things I have in mind. It will
> take some time before I can implement everything, and maybe some points
> will not be implemented in the end if they don't seem to be needed or I
> don't have the time to implement them.
> 
> * Drop Linux 2.4 support. lm-sensors 3.0.x only supports Linux 2.6, so
>   if we no longer keep sensors-detect versions in sync, there's no point
>   in supporting 2.4 kernels in the lm-sensors 3.0.x one. This will make
>   the script somewhat smaller and simpler.
> 
> * Revert the order of the probes. This it ticket #2322:
>   http://www.lm-sensors.org/ticket/2322
>   The idea is to start with the less risky probes, and stop by default
>   when we think we have found what we were looking for. The user will
>   still be able to continue with the detection if he/she wants.
> 
> * SMBus read cache. I submitted something already over one year ago:
>   http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018749.html
>   But nobody reacted so I never committed my work. The speedup
>   generated by this patch alone seemed worth the extra code. Another
>   reason now is that limiting the hardware access to these devices
>   seems to be a good idea in the light of recent reports we had about
>   I2C/SMBus chips reacting to probes in odd ways. The most important
>   protection measures have been implemented in 3.0.2 already, but I
>   believe that caching the register reads in sensors-detect would
>   further prevent the possibility to break something accidentally.
> 

Is this really worth it? The problems with the one register chip won't be 
stopped by this as one read transaction is all it takes to foobar things there. 
Also speed is hardly an argument, it is not like sensors-detect takes a long 
time to run. And as long as it stays within 5 minutes speed is irrelevant IMHO.

> * Get the bus driver names from the kernel. The Linux 2.6 kernel tells
>   you which kernel module provides support for a given driver, so we can
>   stop guessing it with tricky regexp matching against the i2c bus
>   names.
> 
> * Fix the bus numbering prediction magic. There's some old code to
>   attempt to figure out how I2C bus will be numbered after next reboot,
>   so that the "ignore" module options are correct. This code is broken
>   in more than one way. It assumes that it knows about all drivers which
>   create i2c buses, which is not true (all graphics and multimedia
>   adapters in particular are missing.) It assumes that the user will
>   reboot after running sensors-detect. It assumes that i2c bus drivers
>   don't autoload, while they almost all do by now. And it assumes that
>   the bus numbering is stable over reboot, which is not necessarily the
>   case (I can't think of a fix for this one though.)
> 

I agree, with udev etc, bus numbers simply won't be stable so we should not 
rely on them being stable.

> * DMI integration. This is needed for automatic configuration file
>   download, and could also be welcome to explicitly skip some probes
>   on selected motherboards. Recent kernels export the DMI data so we
>   should not even need to depend on dmidecode. Either way I don't want
>   to add a hard dependency for DMI, so if it's there we use it, if not
>   we'll just do as before.
> 
> * Unload i2c-dev at the end of the probe if we loaded it ourselves?
> 
> That's all I can think about at the moment but there is certainly more.
> I would welcome comments on any of the points above.
> 

All in all this sounds very good to me, I esp. look forward to having some dmi 
based probing in sensors-detect, I'm afraid I have little time to spare lately 
but I would be happy to do testing.

Regards,

Hans



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

Re: [lm-sensors] Future plans for sensors-detect

[Jean Delvare]

Hi Hans,

On Wed, 21 May 2008 13:29:55 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > * SMBus read cache. I submitted something already over one year ago:
> >   http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018749.html
> >   But nobody reacted so I never committed my work. The speedup
> >   generated by this patch alone seemed worth the extra code. Another
> >   reason now is that limiting the hardware access to these devices
> >   seems to be a good idea in the light of recent reports we had about
> >   I2C/SMBus chips reacting to probes in odd ways. The most important
> >   protection measures have been implemented in 3.0.2 already, but I
> >   believe that caching the register reads in sensors-detect would
> >   further prevent the possibility to break something accidentally.
> 
> Is this really worth it? The problems with the one register chip won't be 
> stopped by this as one read transaction is all it takes to foobar things there. 

I agree that this approach won't solve the one-register-only device
problem, nor any other problem of that nature (but hopefully the
changes that went in 3.0.2 addressed most of these.) By definition, a
register cache will only avoid reads that have already happened before.

There is still a thin chance that an exact sequence of reads causes
problem to a given chip. Also think of concurrent accesses to a given
chip by ACPI or SMM code: the less reads we do, the less likely they
are to happen. Of course, ideally we would prevent these concurrent
accesses in the kernel directly, but we don't have that at the moment,
and I can't see it done in the next few months (nor years to be honest.)

So I still see a small a value to a register cache in this area.

> Also speed is hardly an argument, it is not like sensors-detect takes a long 
> time to run. And as long as it stays within 5 minutes speed is irrelevant IMHO.

5 minutes? You must be kidding. Any device detection that takes more
than a few _seconds_ is considered too slow by most users.

What worries me and motivated my work in this area, is that our current
code makes the detection slower and slower over time, because we add
support for new devices continuously, but the SMBus doesn't get faster
in the same time. We've added 29 new I2C/SMBus chips over the last 2
years, that's a 30% increase, and I see no reason why it would stop.

I was also thinking that user-friendly distributions might want to
automatize the process of setting up the sensors as part of the system
installation. There are many improvements needed before this can
happen, such as a command line interface / non-interactive mode to
sensors-detect and DMI support, but speeding up the detection itself
would also help, I think.

I wouldn't consider it if the patch was intrusive, but it's pretty
small if you look at it.

> > * Fix the bus numbering prediction magic. There's some old code to
> >   attempt to figure out how I2C bus will be numbered after next reboot,
> >   so that the "ignore" module options are correct. This code is broken
> >   in more than one way. It assumes that it knows about all drivers which
> >   create i2c buses, which is not true (all graphics and multimedia
> >   adapters in particular are missing.) It assumes that the user will
> >   reboot after running sensors-detect. It assumes that i2c bus drivers
> >   don't autoload, while they almost all do by now. And it assumes that
> >   the bus numbering is stable over reboot, which is not necessarily the
> >   case (I can't think of a fix for this one though.)
> 
> I agree, with udev etc, bus numbers simply won't be stable so we should not 
> rely on them being stable.

Unfortunately that's the part that cannot be fixed in sensors-detect
alone. The hwmon module parameters assume that we know the i2c bus
numbers in advance and that they don't change. I have no idea how to
fix this - short of moving clone detection and preventing
mis-detections inside the drivers themselves.

> > * DMI integration. This is needed for automatic configuration file
> >   download, and could also be welcome to explicitly skip some probes
> >   on selected motherboards. Recent kernels export the DMI data so we
> >   should not even need to depend on dmidecode. Either way I don't want
> >   to add a hard dependency for DMI, so if it's there we use it, if not
> >   we'll just do as before.
> (...)
> All in all this sounds very good to me, I esp. look forward to having some dmi 
> based probing in sensors-detect, I'm afraid I have little time to spare lately 
> but I would be happy to do testing.

Same here... I would like to see it implemented, but so far time
constraints never let me look into it.

-- 
Jean Delvare

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

Re: [lm-sensors] Future plans for sensors-detect

[Juerg Haefliger]

[-- Attachment #1.1: Type: text/plain, Size: 5291 bytes --]

Hi Jean, Hans,

While we're at it, can we also fix the format/indentation of the script?
It's always been a thorn in my eye. I'd be glad to do it.

...juerg


On Thu, May 22, 2008 at 4:50 AM, Jean Delvare <khali@linux-fr.org> wrote:

> Hi Hans,
>
> On Wed, 21 May 2008 13:29:55 +0200, Hans de Goede wrote:
> > Jean Delvare wrote:
> > > * SMBus read cache. I submitted something already over one year ago:
> > >
> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018749.html
> > >   But nobody reacted so I never committed my work. The speedup
> > >   generated by this patch alone seemed worth the extra code. Another
> > >   reason now is that limiting the hardware access to these devices
> > >   seems to be a good idea in the light of recent reports we had about
> > >   I2C/SMBus chips reacting to probes in odd ways. The most important
> > >   protection measures have been implemented in 3.0.2 already, but I
> > >   believe that caching the register reads in sensors-detect would
> > >   further prevent the possibility to break something accidentally.
> >
> > Is this really worth it? The problems with the one register chip won't be
> > stopped by this as one read transaction is all it takes to foobar things
> there.
>
> I agree that this approach won't solve the one-register-only device
> problem, nor any other problem of that nature (but hopefully the
> changes that went in 3.0.2 addressed most of these.) By definition, a
> register cache will only avoid reads that have already happened before.
>
> There is still a thin chance that an exact sequence of reads causes
> problem to a given chip. Also think of concurrent accesses to a given
> chip by ACPI or SMM code: the less reads we do, the less likely they
> are to happen. Of course, ideally we would prevent these concurrent
> accesses in the kernel directly, but we don't have that at the moment,
> and I can't see it done in the next few months (nor years to be honest.)
>
> So I still see a small a value to a register cache in this area.
>
> > Also speed is hardly an argument, it is not like sensors-detect takes a
> long
> > time to run. And as long as it stays within 5 minutes speed is irrelevant
> IMHO.
>
> 5 minutes? You must be kidding. Any device detection that takes more
> than a few _seconds_ is considered too slow by most users.
>
> What worries me and motivated my work in this area, is that our current
> code makes the detection slower and slower over time, because we add
> support for new devices continuously, but the SMBus doesn't get faster
> in the same time. We've added 29 new I2C/SMBus chips over the last 2
> years, that's a 30% increase, and I see no reason why it would stop.
>
> I was also thinking that user-friendly distributions might want to
> automatize the process of setting up the sensors as part of the system
> installation. There are many improvements needed before this can
> happen, such as a command line interface / non-interactive mode to
> sensors-detect and DMI support, but speeding up the detection itself
> would also help, I think.
>
> I wouldn't consider it if the patch was intrusive, but it's pretty
> small if you look at it.
>
> > > * Fix the bus numbering prediction magic. There's some old code to
> > >   attempt to figure out how I2C bus will be numbered after next reboot,
> > >   so that the "ignore" module options are correct. This code is broken
> > >   in more than one way. It assumes that it knows about all drivers
> which
> > >   create i2c buses, which is not true (all graphics and multimedia
> > >   adapters in particular are missing.) It assumes that the user will
> > >   reboot after running sensors-detect. It assumes that i2c bus drivers
> > >   don't autoload, while they almost all do by now. And it assumes that
> > >   the bus numbering is stable over reboot, which is not necessarily the
> > >   case (I can't think of a fix for this one though.)
> >
> > I agree, with udev etc, bus numbers simply won't be stable so we should
> not
> > rely on them being stable.
>
> Unfortunately that's the part that cannot be fixed in sensors-detect
> alone. The hwmon module parameters assume that we know the i2c bus
> numbers in advance and that they don't change. I have no idea how to
> fix this - short of moving clone detection and preventing
> mis-detections inside the drivers themselves.
>
> > > * DMI integration. This is needed for automatic configuration file
> > >   download, and could also be welcome to explicitly skip some probes
> > >   on selected motherboards. Recent kernels export the DMI data so we
> > >   should not even need to depend on dmidecode. Either way I don't want
> > >   to add a hard dependency for DMI, so if it's there we use it, if not
> > >   we'll just do as before.
> > (...)
> > All in all this sounds very good to me, I esp. look forward to having
> some dmi
> > based probing in sensors-detect, I'm afraid I have little time to spare
> lately
> > but I would be happy to do testing.
>
> Same here... I would like to see it implemented, but so far time
> constraints never let me look into it.
>
> --
> Jean Delvare
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

[-- Attachment #1.2: Type: text/html, Size: 6580 bytes --]

[-- Attachment #2: 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] Future plans for sensors-detect

[Jean Delvare]

Hi Juerg,

On Fri, 23 May 2008 15:13:50 -0700, Juerg Haefliger wrote:
> While we're at it, can we also fix the format/indentation of the script?
> It's always been a thorn in my eye. I'd be glad to do it.

Certainly. I've done a few cleanups in that direction already (trailing
spaces, missing spaces, extra spaces, curly brace placement) but feel
free to do more.

-- 
Jean Delvare

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

Re: [lm-sensors] Future plans for sensors-detect

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> For completeness...
> 
>> I was also thinking that user-friendly distributions might want to
>> automatize the process of setting up the sensors as part of the system
>> installation. There are many improvements needed before this can
>> happen, such as a command line interface / non-interactive mode to
>> sensors-detect and DMI support, but speeding up the detection itself
>> would also help, I think.
> 
> Note: when sensors-detect goes non-interactive, you are more likely to
> notice how slow SMBus probing is. For now, most time is wasted waiting
> for the user to answer questions, so you don't really notice, unless
> you're using HZ\x100.
> 

Are you really planning on doing non interactive i2c probing from the 
initscript? To me that feels wrong:
1) Only 101% safe probing should be done non interactive
2) Even if we can safely determine which hwmon drivers should be loaded,
    we still should not load them without also having a valid
    matching motherboard sensors.conf

The reason for 2 is that its better to show no readings to an uneducated users 
then to show wrong readings which make him/her think his/her machine is about 
to blow up.

>> I wouldn't consider it if the patch was intrusive, but it's pretty
>> small if you look at it.
> 
> After removing the word register cache (recent changes to the script
> make it hardly worth caching word reads) and the instrumentation code,
> the patch only adds 8 lines of code. The diffstat reads:
> 

I guess its worth it then :)

Regards,

Hans

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

Re: [lm-sensors] Future plans for sensors-detect

[Jean Delvare]

Hi Hans,

On Sun, 25 May 2008 23:20:40 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > Note: when sensors-detect goes non-interactive, you are more likely to
> > notice how slow SMBus probing is. For now, most time is wasted waiting
> > for the user to answer questions, so you don't really notice, unless
> > you're using HZ\x100.
> 
> Are you really planning on doing non interactive i2c probing from the 
> initscript? To me that feels wrong:

Not from init script, that would be too costly to do the detection
again at each boot. I was thinking of adding it as part of the
distribution installation (actually post-install of the sensors
package.) This won't cover the case where the user changes motherboards
without reinstalling his/her system. Maybe we can have a detection of
this case at boot (based on DMI data for example) and we restart the
detection conditionally then.

> 1) Only 101% safe probing should be done non interactive

Same is true of an interactive script. If the default answers aren't
101% safe, we're doing something wrong. That was the case of
sensors-detect up to version 3.0.1, and honestly it might still be the
case in 3.0.2. That's the reason why I proposed to revert the order of
the probes, and to skip probing the SMBus if we have already found a
Super-I/O with sensors or an ISA hardware monitoring chip. Other
possibilities to explore would be to change the probe order of the I2C
addresses (probing 0x2c-0x2f first, 0x48-0x4f second, and only then try
the other addresses, would make a lot of sense IMHO) or doing some
probes conditional (for example, no point in searching for FSC chips on
non-FSC machines).

Don't get me wrong, I'm not going to make sensors-detect
non-interactive and add it to some init script unconditionally
tomorrow. This is part of a much longer process, first making
sensors-detect safer than it is (lot of work here), adding DMI-based
detection to skip probing entirely on known machines (again, lot of
work here), and only then implementing a non-interactive mode. The
non-interactive mode might not do all the possible probings, i.e. we
exclude any probe that we think is dangerous. This might as well mean
not doing any SMBus detection at all, although I hope that we can do
some.

> 2) Even if we can safely determine which hwmon drivers should be loaded,
>     we still should not load them without also having a valid
>     matching motherboard sensors.conf
> 
> The reason for 2 is that its better to show no readings to an uneducated users 
> then to show wrong readings which make him/her think his/her machine is about 
> to blow up.

Again this is unrelated to making sensors-detect non-interactive. We
already ship a default sensors.conf file which includes arbitrary
labels for many chips, which may or may not match the user's
motherboard. This is IMHO plain wrong, I agree with you that
unconfigured sensors are better than misconfigured sensors. I believe
that we should strip down sensors.conf.eg to only include labels which
we know are always correct (e.g. internal voltage labels.) This would
also make libsensors initialization much faster - for now we waste
users' time reading long configuration sections for chips they don't
even have.

> > After removing the word register cache (recent changes to the script
> > make it hardly worth caching word reads) and the instrumentation code,
> > the patch only adds 8 lines of code. The diffstat reads:
> 
> I guess its worth it then :)

I'll commit it later today.

-- 
Jean Delvare

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

Re: [lm-sensors] Future plans for sensors-detect

[Jean Delvare]

On Mon, 26 May 2008 12:06:10 +0200, Jean Delvare wrote:
> We already ship a default sensors.conf file which includes arbitrary
> labels for many chips, which may or may not match the user's
> motherboard. This is IMHO plain wrong, I agree with you that
> unconfigured sensors are better than misconfigured sensors. I believe
> that we should strip down sensors.conf.eg to only include labels which
> we know are always correct (e.g. internal voltage labels.) This would
> also make libsensors initialization much faster - for now we waste
> users' time reading long configuration sections for chips they don't
> even have.

I don't have the time to work on this right now, but have created
ticket #2333 so that we don't forget about it.

-- 
Jean Delvare

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