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
