Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751808AbdF1RjG (ORCPT ); Wed, 28 Jun 2017 13:39:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:44184 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751524AbdF1Ri7 (ORCPT ); Wed, 28 Jun 2017 13:38:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 46AAD22B5F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 28 Jun 2017 13:38:55 -0400 From: Steven Rostedt To: Borislav Petkov Cc: James Morse , Xie XiuQi , Punit Agrawal , "Baicar, Tyler" , ard.biesheuvel@linaro.org, bristot@redhat.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, zhengqiang10@huawei.com, shiju.jose@huawei.com, fu.wei@linaro.org, wangxiongfeng2@huawei.com Subject: Re: [PATCH v5] trace: ras: add ARM processor error information trace event Message-ID: <20170628133855.65509c93@gandalf.local.home> In-Reply-To: <20170628165514.kltemqgaxxhgw5as@pd.tnic> References: <1498275503-137890-1-git-send-email-xiexiuqi@huawei.com> <20170626140647.anigiqhk3l6ltet7@pd.tnic> <5953DC82.2000602@arm.com> <20170628165514.kltemqgaxxhgw5as@pd.tnic> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1240 Lines: 31 On Wed, 28 Jun 2017 18:55:14 +0200 Borislav Petkov wrote: > > but only keep the number of fields we export to a minimum. If we > > always use the names in the spec, and user-space always parses the > > 'format' file, we should be able to add more fields when they turn out > > to be necessary. (looks like the trace infrastructure makes inventing > > a new format easy!) > > Right, except if you have userspace consumers already using them, you're > potentially breaking them. Unless you teach them all to parse the format > file first, from the very beginning. But in general, we try to be very > wary when touching tracepoints as they become an ABI of sorts. No no. You can add new fields easily. There should be no breakage, as the userspace tools should be using the traceevent library code. It only breaks when you remove a field. Which reminds me, I really need to get that out into distros *this* year. I've been putting this off for far too long. The ras tool has its own copy of the traceevent library parser. -- Steve > > Also, do try to shovel only the really needed info to userspace - not > everything the spec dumps but maybe just the fields that are really > necessary for doing hw error recovery. >