Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964809Ab2ERVMc (ORCPT ); Fri, 18 May 2012 17:12:32 -0400 Received: from s15943758.onlinehome-server.info ([217.160.130.188]:42422 "EHLO mail.x86-64.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965340Ab2ERVMa (ORCPT ); Fri, 18 May 2012 17:12:30 -0400 Date: Fri, 18 May 2012 23:12:11 +0200 From: Borislav Petkov To: "Luck, Tony" Cc: Borislav Petkov , Mauro Carvalho Chehab , Ingo Molnar , Linux Edac Mailing List , Linux Kernel Mailing List , Aristeu Rozanski , Doug Thompson , Steven Rostedt , Frederic Weisbecker , Ingo Molnar Subject: Re: [PATCH v24b] RAS: Add a tracepoint for reporting memory controller events Message-ID: <20120518211211.GA26464@aftab.osrc.amd.com> References: <20120518095638.GA20215@aftab.osrc.amd.com> <4FB62BAB.90808@redhat.com> <20120518124338.GJ20215@aftab.osrc.amd.com> <4FB64D5B.1030301@redhat.com> <20120518140521.GM20215@aftab.osrc.amd.com> <4FB65D52.9060108@redhat.com> <20120518164014.GX20215@aftab.osrc.amd.com> <4FB6866E.7090503@redhat.com> <20120518185258.GE20215@aftab.osrc.amd.com> <3908561D78D1C84285E8C5FCA982C28F192F1A33@ORSMSX104.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F192F1A33@ORSMSX104.amr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1678 Lines: 48 On Fri, May 18, 2012 at 07:10:42PM +0000, Luck, Tony wrote: > > 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). Makes sense, I gotta say :) > 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. How about we put all the values which are globally valid for all drivers in separate fields and leave the "(...)" brackets for details where each driver can put its own relevant stuff? For the record, I very much like this reasoning :). -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/