Re: [dpdk-dev] [PATCH] mk: added make target to print out system info

["Mcnamara, John" <john.mcnamara@intel.com>]

> -----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
> 
> > 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
> 
> All I'm saying here is that if we want to provide this functionality we
> need to do one of the following:
> 
> 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:
> 		<do bsd collection>
> 	CASE LINUX:
> 		<do linux collection>
> 	CASE OSV:
> 		<do osv collection>
> }
> 
> Where each case either cats a file or runs an appropriate tool (making the
> appropriate check for its avilability when needed).
> 
> Or
> 
> 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.
> 
> Given that we are likely to be talking about developers here, I'm inclined
> to go with option 2, given that its less maintenence to keep up with.
> 

Hi Neil,

I think you are probably right that documentation is the way to deal with this. 

I'll drop the patch and submit a checklist document with information that should be supplied when reporting bugs. It doesn't have to be added to the DPDK docs. It could be added to dpdk.org or just live in an email on the mailing 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 practice.

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 OSes can add similar text if they think it is useful.

John