From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 2E8B29A9E for ; Wed, 25 Mar 2015 18:57:32 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YapYQ-0001xF-94; Wed, 25 Mar 2015 13:57:28 -0400 Date: Wed, 25 Mar 2015 13:57:21 -0400 From: Neil Horman To: Olivier MATZ Message-ID: <20150325175721.GD18878@hmsreliant.think-freely.org> 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> <5512F38A.40401@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5512F38A.40401@6wind.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 17:57:32 -0000 On Wed, Mar 25, 2015 at 06:42:34PM +0100, Olivier MATZ wrote: > On 03/25/2015 06:22 PM, Neil Horman wrote: > >On Wed, Mar 25, 2015 at 04:42:23PM +0100, Olivier MATZ wrote: > >>On 03/25/2015 04:22 PM, Neil Horman wrote: > >>>On Wed, Mar 25, 2015 at 04:06:10PM +0100, Olivier MATZ wrote: > >>>>Hi, > >>>> > >>>>On 03/24/2015 06:00 PM, Neil Horman wrote: > >>>>>On Tue, Mar 24, 2015 at 02:52:59PM +0000, John McNamara wrote: > >>>>>>Added a 'make system_info' target to print out system info > >>>>>>related to DPDK. This is intended as output that can be > >>>>>>attached to bug reports. > >>>>>>--- > >>>>>> mk/rte.sdkroot.mk | 33 +++++++++++++++++++++++++++++++++ > >>>>>> 1 file changed, 33 insertions(+) > >>>>>> > >>>>>>diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk > >>>>>>index e8423b0..b477d09 100644 > >>>>>>--- a/mk/rte.sdkroot.mk > >>>>>>+++ b/mk/rte.sdkroot.mk > >>>>>>@@ -123,3 +123,36 @@ examples examples_clean: > >>>>>> %: > >>>>>> $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkconfig.mk checkconfig > >>>>>> $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkbuild.mk $@ > >>>>>>+ > >>>>>>+.PHONY: system_info > >>>>>>+system_info: > >>>>>>+ $(Q)echo > >>>>>>+ $(Q)echo "CC version" > >>>>>>+ $(Q)echo "==========" > >>>>>>+ $(Q)$(CC) --version > >>>>>>+ $(Q)echo > >>>>>>+ > >>>>>>+ $(Q)echo "DPDK version" > >>>>>>+ $(Q)echo "============" > >>>>>>+ $(Q)$(MAKE) showversion > >>>>>>+ $(Q)echo > >>>>>>+ > >>>>>>+ $(Q)echo "Git commit" > >>>>>>+ $(Q)echo "==========" > >>>>>>+ $(Q)git log --pretty=format:'%H' -1 > >>>>>>+ $(Q)echo > >>>>>>+ > >>>>>>+ $(Q)echo "Uname" > >>>>>>+ $(Q)echo "=====" > >>>>>>+ $(Q)uname -srvmpio > >>>>>>+ $(Q)echo > >>>>>>+ > >>>>>>+ $(Q)echo "Hugepages" > >>>>>>+ $(Q)echo "=========" > >>>>>>+ $(Q)grep -i huge /proc/meminfo > >>>>>>+ $(Q)echo > >>>>>>+ > >>>>>>+ $(Q)tools/cpu_layout.py > >>>>>>+ > >>>>>>+ $(Q)tools/dpdk_nic_bind.py --status > >>>>>>+ $(Q)echo > >>>>>>-- > >>>>>>1.8.1.4 > >>>>>> > >>>>>> > >>>>>Nak, for a few reasons: > >>>>> > >>>>>1) While this target is in a common makefile, at least some of the information > >>>>>it gathers is operating system specfic (e.g. /proc/meminfo). This isn't going > >>>>>to work on BSD, or other operating systems that we might support in the future > >>>>> > >>>>>2) This is tied to the build system. Theres no guarantee that users will > >>>>>diagnose problems only on the system that they built the DPDK on. > >>>>> > >>>>>A better solution might be to simply document the sort of information that a bug > >>>>>reporter is expected to gather, along with some sample tools for doing so. > >>>>>There are numerous tools to get the above information, both in isolation and in > >>>>>aggregate. > >>>> > >>>>I agree with Neil that the Makefile is probably not the best place to > >>>>put that because the target machine may not be the build machine. What > >>>>about doing the same in a script? Therefore it could be embedded and > >>>>executed on the target. > >>>> > >>>A script would be fine, as long as its cased for tools available on every OS. > >>> > >>>>Neil, you talk about tools that do the same kind of things. What tool > >>>>are you thinking about? The problem of using external tools is that it > >>>>adds a dependency with them. > >>>> > >>>Yes, but how is that different from the above? running cat /proc/meminfo has a > >>>dependency on the existance of /proc/meminfo, which is involate on BSD. Theres > >>>another file there that hold simmilar memory information, though, or perhaps a > >>>memstat tool (I cant recall which). The point being, to have an appropriate bug > >>>reporting tool like this, you need to determine what information you need, then > >>>for each operating system you have to do the right things to get it, be that > >>>read a file, run a tool, or some other operation. > >> > >>Agree, there's no guarantee that /proc/some/file exists on a linux > >>distribution as there is no guarantee that an application is available. > >> > >Agreed. > > > >>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 > > I'm just saying that on linux it is much more likely to have > /proc/meminfo (which is available since at least 2.4.x kernel) instead > of having a rare package providing a tool able to format /proc/meminfo. > Ok, I think either I was unclear, or you misunderstood. I'm in now way opposed to executing /proc/meminfo when its available, Im just saying that we have to do it in the 'linux case' of the pseudo code below. We need to do something different for BSD/OSV because they don't have /proc/meminfo. They may have a different file to read, or need a specific tool to run. the one thing we can do is just unilaterally run cat /proc/meminfo because on any non-linux platform, you won't get any data, which is the goal. I'm fine with just documenting the ways to get it, or codifying it in a script, I'm just pointing out that a script will have to be special cased for each OS Neil