From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 5E9597EB0 for ; Wed, 25 Mar 2015 16:42:23 +0100 (CET) Received: by wgra20 with SMTP id a20so32140597wgr.3 for ; Wed, 25 Mar 2015 08:42:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hFIR7B32vrTHcI48h8Gjqa92BwGCz2f9JOLMWMLiO0Y=; b=Lg0U/v/INNClls1tuFC5KuSHA/vVbFTmNQcWGLBnjugNPzdI4TxBNCYg9xBLoykj6W O60hNoaecON0D473v2ptgwgDfXJGz9LVVENy5GwMP/CkS26b0zzWbemhiE41XbmG2Plk h7ki1QtEv4XKLGorOpp7UsGFX55JooC9wG9GWyF2C0E7/B41o8fhunR72aZNB4g8mJyF UJZBirNqipRRXR+8b8geguhHcQVJilbQuRA77FTItU+mqtq7W6ZiEavL4S5pdGx4FEMu 83NQMFS7Yj4J5FM9JwKnURB5JDLNK52pXfsMDE5oZ/u5gaibU7oA6QJRlVskeJHKDImO 4/jQ== X-Gm-Message-State: ALoCoQkv5eBxeJzg9LXa0i4KpoZ8JYuOnxJNtU81HSpa2A0gNQNYshpjy2uTqmggRVbFqsy90GfC X-Received: by 10.180.84.99 with SMTP id x3mr20657109wiy.35.1427298143217; Wed, 25 Mar 2015 08:42:23 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id u10sm860399wib.1.2015.03.25.08.42.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 08:42:22 -0700 (PDT) Message-ID: <5512D75F.7020303@6wind.com> Date: Wed, 25 Mar 2015 16:42:23 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Neil Horman 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> In-Reply-To: <20150325152211.GA18878@hmsreliant.think-freely.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 15:42:23 -0000 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. 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. Regards, Olivier