DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mcnamara, John" <john.mcnamara@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>,
	Olivier MATZ <olivier.matz@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] mk: added make target to print out system info
Date: Wed, 25 Mar 2015 18:11:19 +0000	[thread overview]
Message-ID: <B27915DBBA3421428155699D51E4CFE2EF0475@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <20150325172229.GC18878@hmsreliant.think-freely.org>

> -----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

      parent reply	other threads:[~2015-03-25 18:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-24 14:52 John McNamara
2015-03-24 14:52 ` John McNamara
2015-03-24 17:00   ` Neil Horman
2015-03-25 15:06     ` Olivier MATZ
2015-03-25 15:22       ` Neil Horman
2015-03-25 15:42         ` Olivier MATZ
2015-03-25 17:22           ` Neil Horman
2015-03-25 17:42             ` Olivier MATZ
2015-03-25 17:57               ` Neil Horman
2015-03-25 18:11             ` Mcnamara, John [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B27915DBBA3421428155699D51E4CFE2EF0475@IRSMSX103.ger.corp.intel.com \
    --to=john.mcnamara@intel.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.com \
    --cc=olivier.matz@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).