From: Jean Delvare <khali@linux-fr.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Problem with order of module loading
Date: Wed, 28 Jan 2009 08:06:28 +0000 [thread overview]
Message-ID: <20090128090628.5aca12ff@hyperion.delvare> (raw)
In-Reply-To: <20090125021151.GE16739@paradise.net.nz>
On Mon, 26 Jan 2009 15:57:10 +0100, Jean Delvare wrote:
> On Mon, 26 Jan 2009 22:47:36 +1300, Volker Kuhlmann wrote:
> > On Mon 26 Jan 2009 02:47:24 NZDT +1300, Jean Delvare wrote:
> > > I'm not sure why you think my approach wouldn't work. Let's take the
> > > case of your board: the k8temp driver loads automatically, the it87
> > > driver doesn't.
> > >
> > > At first run, sensors-detect would stop the lm_sensors service (no
> > > effect as the service wasn't configured yet.) It would detect k8temp and
> > > it87, but seeing that k8temp is already loaded, would only list it87
> > > in /etc/sysconfig/lm_sensors.
> > >
> > > At this point, starting the lm_sensors service only loads it87, because
> > > k8temp is already loaded. Likewise, stopping or restarting the
> > > lm_sensors service only unloads the it87 driver.
> > >
> > > This means that a further run of sensors-detect will only unload the
> > > it87 driver. Then it will see that k8temp is loaded and again will not
> > > list it in /etc/sysconfig/lm_sensors.
> >
> > Ah yes, put it like that, it should work. It would be very sensitive to
> > run-status being the same as boot-status though. Is this robust enough?
>
> I agree it is a little fragile. It should work in the general case if
> the user doesn't edit the configuration file manually and doesn't load
> or unload hwmon drivers on its own. My hope is that users who start
> loading or unloading drivers or editing configuration files will know
> how to fix things if they break. But maybe that's too optimistic.
I have discussed this a bit with Kay Sievers yesterday. He suggested
that we can use the modalias files in sysfs together with "modprobe -n"
to find out whether a loaded hwmon driver has been auto-loaded or not.
This would let us exclude kernel modules from /etc/sysconfig/lm_sensors
based on whether they auto-load rather than based on whether they were
loaded when sensors-detect was run. This should be way more robust than
my initial proposal, to a point where I think it would make sense to
give it a try.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2009-01-28 8:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-25 2:11 [lm-sensors] Problem with order of module loading Volker Kuhlmann
2009-01-25 10:00 ` Jean Delvare
2009-01-25 11:08 ` Volker Kuhlmann
2009-01-25 13:47 ` Jean Delvare
2009-01-26 9:47 ` Volker Kuhlmann
2009-01-26 14:57 ` Jean Delvare
2009-01-27 8:27 ` Jean Delvare
2009-01-28 8:06 ` Jean Delvare [this message]
2009-01-30 16:23 ` Jean Delvare
2009-02-04 10:05 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090128090628.5aca12ff@hyperion.delvare \
--to=khali@linux-fr.org \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.