Re: [dpdk-dev] [PATCH 5/5] add FILE arguement to debug functions

[Neil Horman <nhorman@tuxdriver.com>]

On Mon, May 05, 2014 at 06:55:31PM -0700, Stephen Hemminger wrote:
> On Mon, 5 May 2014 06:53:09 -0400
> Neil Horman <nhorman@tuxdriver.com> wrote:
> 
> > On Sun, May 04, 2014 at 01:17:50PM -0700, Stephen Hemminger wrote:
> > > On Sun, 4 May 2014 08:20:54 -0400
> > > Neil Horman <nhorman@tuxdriver.com> wrote:
> > > 
> > > > On Fri, May 02, 2014 at 04:42:56PM -0700, Stephen Hemminger wrote:
> > > > > The DPDK dump functions are useful for remote debugging of an
> > > > > applications. But when application runs as a daemon, stdout
> > > > > is typically routed to /dev/null.
> > > > > 
> > > > > Instead change all these functions to take a stdio FILE * handle
> > > > > instead. An application can then use open_memstream() to capture
> > > > > the output.
> > > > > 
> > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > > > 
> > > > Why not convert these to rte_log calls?  Seems like we already have the
> > > > infrastrucutre here, we just need to use it.
> > > > Neil
> > > > 
> > > 
> > > Because it is useful to have remote console like functionatlity,
> > > and dumping this to log doesn't work for that.
> > > 
> > Why not?  Looking at it it seems to me that you could get this exact same
> > functionality by calling rte_openlog_stream(stdout);
> > 
> > Neil
> > 
> 
> If you have a remote console (per connection) and a thread handling
> those requests you want to direct output of a command like 'show mempool'
> to respond to that request. An existing file descriptor don't work they are global
> no per thread. There is a difference between log and response to request.
> 
ah, sorry, wasn't considering the multiuser case
Neil

>