All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Better generic print fault handling
Date: Sat, 07 Jul 2007 16:38:03 +0000	[thread overview]
Message-ID: <468FC16B.5040503@hhs.nl> (raw)
In-Reply-To: <20070707174935.7d4e56e4@hyperion.delvare>

Jean Delvare wrote:
> On Thu, 5 Jul 2007 23:03:12 +0200 (CEST), lm-sensors-notify@lm-sensors.org wrote:
>>       Author: jwrdegoede
>>         Date: Thu Jul  5 23:03:06 2007
>> New Revision: 4559
>>    Changeset: http://lm-sensors.org/changeset/4559
>>
>> Modified:
>>    lm-sensors/branches/lm-sensors-3.0.0/prog/sensors/chips.c
>>    lm-sensors/branches/lm-sensors-3.0.0/prog/sensors/chips_generic.c
>>
>> Log:
>> Better generic print fault handling
> 
> OK, it works (tested with an ADM1032 in both degrees C and F) but I
> can't say I find using HUGE_VAL particularly aesthetic. I have to admit
> that this was certainly the quickest way to implement proper
> temperature fault handling without changing the temp_print_info()
> signature. But OTOH, temp_print_info() is only called once, so changing
> its signature wouldn't be a big problem.
> 

I know this isn't pretty I started out using NAN (not a numbeR) which was 
better / clearer, but is ISO99, so I thought it would be better to use 
HUGE_VAL. I didn't want to change the prototype as there already way to much 
params as is.

> I guess that the main problem here is that we have an artificial split
> of temp_print_info() outside of the generic temperature printing
> function, while we shouldn't. This explains in part why the this
> generic temperature printing function doesn't look quite good.
> 

Hmm, I don't think putting all the temp_print_info() stuff into the function 
will make it better, maybe it will, but I don't know if a function becomes tom 
large splitting of small sub functions can be a good idea.

Regards,

Hans

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

  reply	other threads:[~2007-07-07 16:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-07 15:49 [lm-sensors] Better generic print fault handling Jean Delvare
2007-07-07 16:38 ` Hans de Goede [this message]
2007-07-07 19:04 ` 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=468FC16B.5040503@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.