From: Guenter Roeck <guenter.roeck@ericsson.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] Adding critical/fault limits to hwmon sysfs API
Date: Wed, 23 Jun 2010 17:21:44 +0000 [thread overview]
Message-ID: <20100623172144.GA20046@ericsson.com> (raw)
In-Reply-To: <20100623183437.5a04dedb@hyperion.delvare>
On Wed, Jun 23, 2010 at 12:34:37PM -0400, Jean Delvare wrote:
> Hi Guenter,
>
> On Wed, 23 Jun 2010 08:03:25 -0700, Guenter Roeck wrote:
> > On Wed, Jun 23, 2010 at 10:29:11AM -0400, Jean Delvare wrote:
> > > I expected a counter-proposal of this kind. The problem I see is that
> > > the new limit we are adding is unrelated to _min. However, the other
> > > _min_* file we have (_min_alarm) expresses something which is relative
> > > to _min. Same as _max_hyst and _crit_hyst, which are relative to _max
> > > and _critn respectively. So I have the feeling that _min_crit sends the
> > > wrong signal to the reader. Especially if we keep _crit for the high
> > > bound, the asymmetry raises questions.
> > >
> > > This is my rationale for suggesting _crit and _lcrit. Now, I won't
> > > argue forever if others disagree, these is really only a naming
> > > convention and everything will be fine as long as the drivers and
> > > libsensors agree.
> >
> > Makes sense. No strong opinion on my side, really. Using crit/lcrit is fine for me as well.
> > Maybe we should wait if there is input from others and go with lcrit if there is none.
>
> OK, fine with me.
>
> > On a side note, libsensors does not support inX_fault today, even though
> > it is mentioned in the API, and there is no currX_fault. Likewise, libsensors supports
> > currX_alarm but it is not mentioned in hwmon/sysfs-interface.
> > Unless there are objections, I'll clean that up when I add support for the _[l]crit objects.
>
> Yes, please!
>
> > Also, lib/sensors.conf.5 has a comment "Likewise, tempX_crit often comes with tempX_max_crit".
> > Since tempX_max_crit does not exist, it might make sense to remove that comment.
>
> Does the sentence make sense if you replace tempX_max_crit with
> tempX_crit_hyst? Looks like a copy-paste-edit mistake (that would be
> from me.)
Yes, I think that is the problem. I'll fix that together with the other changes.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] Adding critical/fault limits to hwmon sysfs API
Date: Wed, 23 Jun 2010 10:21:44 -0700 [thread overview]
Message-ID: <20100623172144.GA20046@ericsson.com> (raw)
In-Reply-To: <20100623183437.5a04dedb@hyperion.delvare>
On Wed, Jun 23, 2010 at 12:34:37PM -0400, Jean Delvare wrote:
> Hi Guenter,
>
> On Wed, 23 Jun 2010 08:03:25 -0700, Guenter Roeck wrote:
> > On Wed, Jun 23, 2010 at 10:29:11AM -0400, Jean Delvare wrote:
> > > I expected a counter-proposal of this kind. The problem I see is that
> > > the new limit we are adding is unrelated to _min. However, the other
> > > _min_* file we have (_min_alarm) expresses something which is relative
> > > to _min. Same as _max_hyst and _crit_hyst, which are relative to _max
> > > and _critn respectively. So I have the feeling that _min_crit sends the
> > > wrong signal to the reader. Especially if we keep _crit for the high
> > > bound, the asymmetry raises questions.
> > >
> > > This is my rationale for suggesting _crit and _lcrit. Now, I won't
> > > argue forever if others disagree, these is really only a naming
> > > convention and everything will be fine as long as the drivers and
> > > libsensors agree.
> >
> > Makes sense. No strong opinion on my side, really. Using crit/lcrit is fine for me as well.
> > Maybe we should wait if there is input from others and go with lcrit if there is none.
>
> OK, fine with me.
>
> > On a side note, libsensors does not support inX_fault today, even though
> > it is mentioned in the API, and there is no currX_fault. Likewise, libsensors supports
> > currX_alarm but it is not mentioned in hwmon/sysfs-interface.
> > Unless there are objections, I'll clean that up when I add support for the _[l]crit objects.
>
> Yes, please!
>
> > Also, lib/sensors.conf.5 has a comment "Likewise, tempX_crit often comes with tempX_max_crit".
> > Since tempX_max_crit does not exist, it might make sense to remove that comment.
>
> Does the sentence make sense if you replace tempX_max_crit with
> tempX_crit_hyst? Looks like a copy-paste-edit mistake (that would be
> from me.)
Yes, I think that is the problem. I'll fix that together with the other changes.
Guenter
next prev parent reply other threads:[~2010-06-23 17:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-20 16:37 [lm-sensors] Adding critical/fault limits to hwmon sysfs API Guenter Roeck
2010-06-20 16:37 ` Guenter Roeck
2010-06-23 12:43 ` [lm-sensors] " Jean Delvare
2010-06-23 12:43 ` Jean Delvare
2010-06-23 13:31 ` Guenter Roeck
2010-06-23 13:31 ` Guenter Roeck
2010-06-23 14:29 ` Jean Delvare
2010-06-23 14:29 ` Jean Delvare
2010-06-23 15:03 ` Guenter Roeck
2010-06-23 15:03 ` Guenter Roeck
2010-06-23 16:34 ` Jean Delvare
2010-06-23 16:34 ` Jean Delvare
2010-06-23 17:21 ` Guenter Roeck [this message]
2010-06-23 17:21 ` Guenter Roeck
2010-06-24 0:09 ` Mark Brown
2010-06-24 0:09 ` Mark Brown
2010-06-24 6:34 ` Jean Delvare
2010-06-24 6:34 ` 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=20100623172144.GA20046@ericsson.com \
--to=guenter.roeck@ericsson.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.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.