All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaromir Capik <jcapik@redhat.com>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH] avoid unwanted sensors-detect termination when the /dev/port is missing
Date: Wed, 23 Jan 2013 12:17:34 +0000	[thread overview]
Message-ID: <1101909607.14015637.1358943454592.JavaMail.root@redhat.com> (raw)
In-Reply-To: <1978493810.11074933.1358435561516.JavaMail.root@redhat.com>

> Hi Jaromir,
> 

Hi Jean.

> On Thu, 17 Jan 2013 10:12:41 -0500 (EST), Jaromir Capik wrote:
> > Hello guys.
> > 
> > The device file /dev/port might be missing in some cases
> > and the sensors detection is terminated when the user
> > tries to detect sensors dependent on it's existence.
> > That's not correct -> it's not a reason for terminating
> > the detection.
> 
> I admit that dying in this case is a little abrupt. That being said,
> without /dev/port, you won't be able to detect Super-I/O chips, ISA
> chips and I/O-based IPMI interfaces, which only leave you with
> I2C/SMBus-based, PCI-based and MSR-based sensors. Are there really
> systems out there without /dev/proc where any of these is present?

Yes, such systems exist. I had the pleasure to debug the issue 
directly on 2 systems where the /dev/port was missing, but
I2C bus was present. One of the systems even didn't have
any PCI bus. And I believe that we can expect more hardware
like that in the future. With ARM based boards even more oddities
can appear. The detection script needs to be as flexible
as possible to handle such situations.


> I am not particularly interested in tweaking sensors-detect for
> theoretical-only cases.
> 
> > The attached patch solves the issue, so that a warning
> > is displayed and the detection continues.
> 
> This is a first step forward, but from a user-friendliness
> perspective
> I'd say it is insufficient. If /dev/port isn't there then you
> shouldn't
> even try to open it, even less try 4 times and display 4 times the
> same
> error message. Instead, you should check for /dev/port absence
> upfront,
> let the user know about that and the limitations it implies, and then
> plain skip all detection steps which you know have no chance of
> succeeding.

Yes, that sounds better. I'm not against any future
modifications. That was just the kick off. 


> 
> > The patch can be applied on the current trunk version.
> > Please, check the patch and merge it if possible.
> 
> I have applied it [1], with an additional STDERR for the error
> message
> destination.

Oh yes, you're right. It needs to go to STDERR.


> 
> [1] http://www.lm-sensors.org/changeset/6116
> 
> --
> Jean Delvare
> 

Thank you.

Regards,
Jaromir.

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

  parent reply	other threads:[~2013-01-23 12:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-17 15:12 [lm-sensors] [PATCH] avoid unwanted sensors-detect termination when the /dev/port is missing Jaromir Capik
2013-01-23  9:35 ` Jean Delvare
2013-01-23 12:17 ` Jaromir Capik [this message]
2013-01-23 13:23 ` 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=1101909607.14015637.1358943454592.JavaMail.root@redhat.com \
    --to=jcapik@redhat.com \
    --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.