From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751629AbdISBKb (ORCPT ); Mon, 18 Sep 2017 21:10:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:44168 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbdISBKa (ORCPT ); Mon, 18 Sep 2017 21:10:30 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 699F221A92 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: Mon, 18 Sep 2017 21:10:27 -0400 From: Steven Rostedt To: "Luck, Tony" Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, Boris Petkov , Fenghua Yu , Reinette Chatre , Vikas Shivappa Subject: Re: [RFC 0/5] x86/intel_rdt: Better diagnostics Message-ID: <20170918211027.2ede5164@gandalf.local.home> In-Reply-To: References: 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 On Mon, 18 Sep 2017 15:18:38 -0700 "Luck, Tony" wrote: > From: Tony Luck > > Chatting online with Boris to diagnose why his test cases for RDT > weren't working, we came up with either a good idea (in which case > I credit Boris) or a dumb one (in which case this is all my fault). > > The basic problem is that there aren't many good error codes for > a file system interface to pass back to the user. I'd resisted > adding printk() calls because it is a pain to parse the console > log, doubly so if you want to do it from a shell script that is > actually issuing the commands to RDT. > > The answer is to add new file in the "info" directory that gives > the status of the last "command" to RDT (either a mkdir, or a > write to one of the control files). > > I used the seq_buf* framework because I initially thought a single > command might result in multiple messages. But currently that isn't > true and we could potentially just use "strcpy()/sprintf()" to a > fixed buffer. I didn't switch to that because the seq_buf* seems > very lightweight and allows for future extra messages while including > checking for exceeding the length of the buffer. > > Tony Luck (5): > x86/intel_rdt: Add framework for better RDT UI diagnostics > x86/intel_rdt: Add diagnostics when writing the schemata file > x86/intel_rdt: Add diagnostics when writing the tasks file > x86/intel_rdt: Add diagnostics when writing the cpus file > x86/intel_rdt: Add diagnostics when making directories > > arch/x86/kernel/cpu/intel_rdt.h | 6 ++ > arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 61 +++++++++++++++---- > arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 93 +++++++++++++++++++++++++---- > 3 files changed, 137 insertions(+), 23 deletions(-) > They all look fine to me. Acked-by: Steven Rostedt (VMware) -- Steve