linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hardware error reporting [was Re: PCI Error reporting]
Date: Tue, 03 Oct 2006 15:57:20 +0000	[thread overview]
Message-ID: <1159891040.3430.36.camel@localhost> (raw)
In-Reply-To: <20061003152636.GA4381@austin.ibm.com>

On Tue, 2006-10-03 at 10:26 -0500, Linas Vepstas wrote:
> > I am the maintainer of the KDE 'task manager' equivalent (kde system
> > guard).  I was discussing with someone in the UK about telling the user
> > about PCI bus errors.  The idea would be to inform the user that their
> > soundcard etc is no longer working etc.

Error classification/reporting is a completely missing piece in Linux.
Today there is no sane example of error reporting in the Linux kernel.
Printk and friends are totally useless for anything else than the geek
in front of the computer. Until the kernel gets a sane error
classification/reporting infrastructure, it's impossible to solve such a
problem.

> Anyway, userspace gets messages from the kernel via "hald"
> (hardware abstraction layer daemon) and the sbus(??)I forget
> what its called, the system message bus. These two are plugged 
> into the udev infrastructure.

Udev listens to kernel messages on the kernel netlink socket and handles
the "low level" stuff like module loading, device node creation, running
small device initialization programs. After udev is finished, it sends
the event to HAL. HAL classifies the device and adds the device to its
own device tree. This list can be queried over DBus by applications,
mostly desktop software. But unfortunately, none of these software
pieces are useful for error reporting today, cause you just don't get
any useful data out of the kernel.
It may be nice to integrate a kernel error classification/reporting
system into HAL, but we don't have such a thing.

And just in case: using the driver-core event-infrastucture (udev) is
the totally wrong approach to relay kernel errors to userspace.

Thanks,
Kay


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  reply	other threads:[~2006-10-03 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-03 15:26 Hardware error reporting [was Re: PCI Error reporting] Linas Vepstas
2006-10-03 15:57 ` Kay Sievers [this message]
2006-10-03 16:01 ` Linas Vepstas
2006-10-03 16:26 ` Linas Vepstas
2006-10-03 21:52 ` Kay Sievers
2006-10-03 23:00 ` Greg KH

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=1159891040.3430.36.camel@localhost \
    --to=kay.sievers@vrfy.org \
    --cc=linux-hotplug@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).