From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id A114B9AAC for ; Wed, 25 Mar 2015 19:11:23 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 25 Mar 2015 11:11:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,466,1422950400"; d="scan'208";a="704119158" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga002.jf.intel.com with ESMTP; 25 Mar 2015 11:11:22 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.143]) by IRSMSX102.ger.corp.intel.com ([169.254.2.9]) with mapi id 14.03.0224.002; Wed, 25 Mar 2015 18:11:20 +0000 From: "Mcnamara, John" To: Neil Horman , Olivier MATZ Thread-Topic: [dpdk-dev] [PATCH] mk: added make target to print out system info Thread-Index: AQHQZkJA+mVOrzgd5ku65jf8dNgnuJ0rt+uAgAAjwgCAAXJCAIAABHqAgAAFpYCAABv3gIAABmWA Date: Wed, 25 Mar 2015 18:11:19 +0000 Message-ID: References: <1427208779-16548-1-git-send-email-john.mcnamara@intel.com> <1427208779-16548-2-git-send-email-john.mcnamara@intel.com> <20150324170058.GA13924@hmsreliant.think-freely.org> <5512CEE2.60202@6wind.com> <20150325152211.GA18878@hmsreliant.think-freely.org> <5512D75F.7020303@6wind.com> <20150325172229.GC18878@hmsreliant.think-freely.org> In-Reply-To: <20150325172229.GC18878@hmsreliant.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] mk: added make target to print out system info X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 18:11:24 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Wednesday, March 25, 2015 5:22 PM > To: Olivier MATZ > Cc: Mcnamara, John; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] mk: added make target to print out system > info >=20 > > For instance, using applications that are packaged in coreutils or > > procps should not be an issue. But I would say that using applications > > included in specific packages should be avoided, and in this case the > > /proc interface can be better. > > > Why? We just agreed that there is no guarantee that a file exists in > /proc, so its no better or worse than using an application which may or > may not be installed. If the file is available, then great, you can use > it, but otherwise you have to provide some alternate method for getting > the data. Just not collecting some of it in my mind makes such a script > not worthwhile >=20 > All I'm saying here is that if we want to provide this functionality we > need to do one of the following: >=20 > 1) Write a script (to remove ourselves from being bound to a build > environment), which codifies the data items we wish to collect for > debugging. For each items we need a case statement of the form: > switch $PLATFORM { > CASE BSD: > > CASE LINUX: > > CASE OSV: > > } >=20 > Where each case either cats a file or runs an appropriate tool (making th= e > appropriate check for its avilability when needed). >=20 > Or >=20 > 2) Document the kind of data that we need when debugging, and make > suggestions in said document for what types of tools/files might provide > that data, and leaving it up to users to do the collection on their own. >=20 > Given that we are likely to be talking about developers here, I'm incline= d > to go with option 2, given that its less maintenence to keep up with. >=20 Hi Neil, I think you are probably right that documentation is the way to deal with t= his.=20 I'll drop the patch and submit a checklist document with information that s= hould be supplied when reporting bugs. It doesn't have to be added to the D= PDK docs. It could be added to dpdk.org or just live in an email on the mai= ling list that we can point people to. The main goal is to avoid having to pull relevant information out of people= over a series of emails. Perhaps it may prove not to be necessary in pract= ice. I can add sample shell scripts for Linux/FreeBSD at the end of the doc, to = cover Oliver's suggestion about consistency of reporting. Users of other OS= es can add similar text if they think it is useful. John