[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F4D7BF9.9070104@jp.fujitsu.com>
Date: Wed, 29 Feb 2012 10:14:33 +0900
From: Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To: Borislav Petkov <bp@...64.org>
CC: Tony Luck <tony.luck@...el.com>, Ingo Molnar <mingo@...e.hu>,
EDAC devel <linux-edac@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Borislav Petkov <borislav.petkov@....com>
Subject: Re: [PATCH 1/3] mce: Add a msg string to the MCE tracepoint
(2012/02/29 1:11), Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@....com>
>
> The idea here is to pass an additional decoded MCE message through
> the tracepoint and into the ring buffer for userspace to consume. The
> designated consumers are RAS daemons and other tools collecting RAS
> information.
I could not catch the point... Why you need this msg field?
I think that all of information about the error is already packed in
the record and that we can make a string from the bits in the record
soon afterward. From my point of view it seems that what you are
doing here is just consuming the ring buffer by repeating same
contents in another format with dynamic length which might be short
but otherwise could be too long.
And one more unacceptable point is that filling this msg field is
expected to be done in machine check context where have many
limitations in kernel's subsystems such as use of memory allocators.
Suggestion; How about having a kind of translator function for
userland, e.g. an exported function named mce_record_to_msg()?
Tool obtains raw data from the record in the tracepoint's ring buffer,
and if it likes, optionally it can pass the record to the translator
function to get some accomplished string.
>
> Drop unneeded fields while at it, thus saving some room in the ring
> buffer.
Really unneeded and should be killed?
Thanks,
H.Seto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists