[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F31CB8DB5@ORSMSX106.amr.corp.intel.com>
Date: Tue, 13 Aug 2013 17:39:00 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
Mauro Carvalho Chehab <m.chehab@...sung.com>
CC: Borislav Petkov <bp@...en8.de>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"rjw@...k.pl" <rjw@...k.pl>,
"lance.ortiz@...com" <lance.ortiz@...com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Aristeu Rozanski Filho" <arozansk@...hat.com>
Subject: RE: [PATCH 3/3] mce: acpi/apei: trace: Enable ghes memory error
trace event
> In the meantime, like Boris suggests, I think we can have a different
> trace event for raw APEI reports - userspace can use it as it pleases.
>
> Once ghes_edac gets better, users can decide whether they want raw APEI
> reports or the EDAC-processed version and choose one or the other trace
> event.
It's cheap to add as many tracepoints as we like - but may be costly to maintain.
Especially if we have to tinker with them later to adjust which things are logged,
that puts a burden on user-space tools to be updated to adapt to the changing
API.
Mauro has written his user-space tool to process the ghes-edac events:
git://git.fedorahosted.org/rasdaemon.git
Who is writing the user space tools to process the new apei tracepoints
you want to add?
I'm not opposed to these patches - just wondering who is taking the next step
to make them useful.
-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