From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by dpdk.org (Postfix) with ESMTP id 05417AFDB for ; Tue, 6 May 2014 03:55:29 +0200 (CEST) Received: by mail-pd0-f171.google.com with SMTP id r10so8754543pdi.16 for ; Mon, 05 May 2014 18:55:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=3vkv59hhVEJJMj75V/o9KtEo72CFzUWsCPLuiCn0VGo=; b=GV7e/kruIEw0TjvduWwAbLJ37leQ0Zjv8E09TFaEWijy6xKMtNsLs00FHkP9BRni/V yyLS/Wg8NZagLn8C5p3Ozn+W+HYM7nRz5VG3q9qYBjyMMvF0SuUsTXI8vNBxWmP/vkMz uIx6A0cwr90TvpI6JzjMugIq2MKXB8d2QnLhukUwwh5gwg40cCzr46GxgaZT49zeBxPl ZbFHUTWnvonA0Jbjo8QtFE7VJsu0++Jr8WFH7X0bkcRPshY13jZw0F1jf/X3y8fKBK2i ejuCSz8xRGbVm++n+Iq+zU5oBp7E0hnZqUQnR1RhK6PqpKm1QQ8w1BMCvInozYoXqPO8 e42w== X-Gm-Message-State: ALoCoQkm2t7BFWoBXKi7uRj5IvyAPcdmO2uNO4KM0npqPp7tBh1OVpRjnG1/0+NFrT3xeq6QtgFS X-Received: by 10.66.231.40 with SMTP id td8mr807455pac.103.1399341334746; Mon, 05 May 2014 18:55:34 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-83-51.bvtn.or.frontiernet.net. [50.53.83.51]) by mx.google.com with ESMTPSA id f5sm84706329pat.11.2014.05.05.18.55.34 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 05 May 2014 18:55:34 -0700 (PDT) Date: Mon, 5 May 2014 18:55:31 -0700 From: Stephen Hemminger To: Neil Horman Message-ID: <20140505185531.4dbd94d4@nehalam.linuxnetplumber.net> In-Reply-To: <20140505105309.GD16114@hmsreliant.think-freely.org> References: <20140502234251.707598579@vyatta.com> <20140502234407.841791092@vyatta.com> <20140504122053.GA5012@localhost.localdomain> <20140504131750.45409335@nehalam.linuxnetplumber.net> <20140505105309.GD16114@hmsreliant.think-freely.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 5/5] add FILE arguement to debug functions 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: Tue, 06 May 2014 01:55:30 -0000 On Mon, 5 May 2014 06:53:09 -0400 Neil Horman 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 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 > > > > > > > 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.