[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F192F1A33@ORSMSX104.amr.corp.intel.com>
Date: Fri, 18 May 2012 19:10:42 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...64.org>,
Mauro Carvalho Chehab <mchehab@...hat.com>
CC: Ingo Molnar <mingo@...nel.org>,
Linux Edac Mailing List <linux-edac@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Aristeu Rozanski <arozansk@...hat.com>,
Doug Thompson <norsk5@...oo.com>,
Steven Rostedt <rostedt@...dmis.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...hat.com>
Subject: RE: [PATCH v24b] RAS: Add a tracepoint for reporting memory
controller events
> That's why _each_ _driver_ will have its format and the userspace tools
> parsing it will know about it!
Sounds like a full employment program for parser writers.
There are some interesting fields that should be common to all
drivers ... so have twenty parsers that can handle:
paddr: 0x1234
PADDR: 0x1234
Paddr = 0x1234
Phys = 1234
addr: 0x1234
Address: 0x000000001234
looks like a lot of make-work ... when the OS can standardize in the ABI
that there is a 64-bit binary value that is the physical address of the
error (and another 64-bit mask saying which, if any, bits are valid).
So we should be looking for the set of always relevant values that can
be kept explicitly separate in fields in TP_PROTO, and per-driver specific
stuff (grain/syndrome??) bits that will have to go into the "details"
string and require some driver specific user-mode parsing to use.
-Tony
--
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