From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Fault files naming convention
Date: Sat, 26 May 2007 07:17:27 +0000 [thread overview]
Message-ID: <4657DF07.1030008@hhs.nl> (raw)
In-Reply-To: <20070525191053.16166460@hyperion.delvare>
Juerg Haefliger wrote:
> Jean,
>
> Personally, I like the short names better. The additional 'input' in
> the long name doesn't add any value in my opinion. And as you
> mentioned, using short names would make it consistent with alarms and
> beeps.
>
> ...juerg
>
+1,
Hans
>
> On 5/25/07, Jean Delvare <khali@linux-fr.org> wrote:
>> Hi all,
>>
>> We have the following naming convention documented in
>> Documentation/hwmon/sysfs-interface for fault files:
>>
>> in[0-*]_input_fault
>> fan[1-*]_input_fault
>> temp[1-*]_input_fault
>>
>> Some drivers follow this convention (lm63, lm83, lm90, smsc47m192).
>> However some drivers omit the "input" part and create files named
>> fan1_fault (pc87427) or temp1_fault (dme1737). And the new "generic"
>> libsensors follows this second (non-standard) convention, so it fails
>> to report fault conditions for drivers which follow the standard.
>>
>> We need to fix it all up so that we have a single convention and
>> libsensors uses it. I would fix the drivers which do not follow the
>> standard, and libsensors, however I start wondering if the short names
>> aren't better. After all, we don't include the "input" part in alarm
>> and beep file names, so it is questionable why we do it for fault
>> conditions. Well, it might make some sense, but on the other hand the
>> short name isn't ambiguous as far as I can see, so it would work too.
>> So I just don't know. But what I know is that we must fix it quickly.
>> Anyone has an opinion on why the long or the short names would be
>> preferable?
>>
>> Thanks,
>> --
>> Jean Delvare
>>
>> _______________________________________________
>> lm-sensors mailing list
>> lm-sensors@lm-sensors.org
>> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
prev parent reply other threads:[~2007-05-26 7:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-25 17:10 [lm-sensors] Fault files naming convention Jean Delvare
2007-05-25 22:21 ` Juerg Haefliger
2007-05-26 7:17 ` Hans de Goede [this message]
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=4657DF07.1030008@hhs.nl \
--to=j.w.r.degoede@hhs.nl \
--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.