All of
 help / color / mirror / Atom feed
From: Jim Keniston <>
To: Andrew Morton <>
Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting
Date: Tue, 08 Jul 2003 12:22:44 -0700	[thread overview]
Message-ID: <> (raw)

Andrew Morton wrote:
> Jim Keniston <> wrote:
> >
> > The enclosed patches provide a mechanism for reporting error events
> > to user-mode applications via netlink.
> Seems sane to me.
> It needs to handle %z as well as %Z.

Yes, thanks.  I missed that change to vsnprintf().

> The layout of `struct kern_log_entry' may be problematic.  Think of the
> situation where a 64-bit kernel constructs one of these and sends it up to
> 32-bit userspace.  Will the structure layout be the same under the 32-bit
> compiler as under the 64-bit one?

I think so.  Nothing is bigger than 4 bytes except log_facility[] (16-byte
array of char, which doesn't induce padding at all on i386).  But I will find a
64K/32U ppc machine and check that.

> How do you actually intend to use this?

I envision it being used by a configuration/status-monitoring system that monitors
hotplug events, sysfs, etc. for configuration changes, and listens to the
proposed interface for error events.  Binary-only events (logged with evl_write())
would have to be interpreted based on knowledge existing entirely in user space (either
coded into the monitor program, or provided as supplementary information via a formatting
template or some such).  PRINTF-format events can carry and/or be supplemented with
similar info, but have the error message built in.

> Will it be by adding new
> evt_printf() calls to particular drivers, or replacing existing printk's or
> both?

There have been a variety of suggestions for how error reporting could be improved.
Two common ones are:
1. Leave printks alone, and log additional info in whatever format you want via netlink.
(E.g., Dave Miller recommended something like this.)  This proposal supports that.

2. Migrate from raw printks to "smarter" versions -- e.g., dev_printk and friends,
or the proposed netdev_printk.  Such macros now call just printk (after adding
relevant info), but could be modified to call evl_printk as well with the same args.

There are a zillion variations on this, of course...

> Would it make sense for evt_printf() to fall back to printk() if nobody is
> listening to the log stream?

That certainly makes sense for evl_printf.  For evl_write, just do a hex dump or something.
So evlog.c would query kerror.c to see if anybody's listening.  Would kerror.c
consult nl_table[] directly, or is there an anybody_listening() function that
does this?


  reply	other threads:[~2003-07-08 19:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-08 17:31 [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting Jim Keniston
2003-07-08 17:59 ` Andrew Morton
2003-07-08 19:22   ` Jim Keniston [this message]
2003-07-08 19:45   ` Jim Keniston
2003-07-10  4:42 ` James Morris
2003-07-10 19:08   ` Jim Keniston
2003-07-11 15:37     ` James Morris
2003-07-12  5:09       ` David S. Miller
2003-07-12  5:41       ` David S. Miller
2003-07-13  1:17         ` James Morris
2003-07-13  5:34           ` David S. Miller
2003-07-15 17:42           ` [PATCH] [1/2] kernel error reporting (revised) Jim Keniston
2003-07-15 17:45             ` [PATCH] [2/2] " Jim Keniston
2003-07-15 19:51             ` [PATCH] [1/2] " Andrew Morton
2003-07-15 23:10               ` kuznet
2003-07-17 19:13               ` Jim Keniston
2003-07-18  1:53                 ` James Morris
2003-07-18 17:06                   ` Jim Keniston
2003-07-18 23:29                   ` Jim Keniston
2003-07-19 23:52                     ` James Morris
     [not found] <>
     [not found] ` <>
2003-07-08 19:14   ` [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting Andi Kleen

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* 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.