From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id B1BB356A9 for ; Thu, 15 Sep 2016 08:49:51 +0200 (CEST) Received: by mail-wm0-f53.google.com with SMTP id k186so48937493wmd.0 for ; Wed, 14 Sep 2016 23:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=47uqChEzeEajSDIQMD9mkGbRaeWz4iau82Y1pdScTdo=; b=YKpu4DpZXwDcFgK2dUq0o15oUt4uSx9YJ4G252P32+DMceUJGFI498S+fq24cntfgp IudXlkQ5AyFYtwpRu1WhNi/frmvK4NDyH67SIwNksUWK9+SxDg9igk6xpRZ3RFir1Csn UyqgyQeVGZMX19dCJIezmhRBqmiNftmhO1HqtRoTBdGFPUBmRwlhq8G22YH7mgkarrPn LhUguyw6B6H9X5FXpvpwoKcctlr3utqqXLUYeUFG8xW8I+cYI+H7LTxncCKIbrk44Npu mMU/2hbe5rr2tzlPWuxUPZh9v8UfJL3tjpjebhXwkp+fgwWXgOacvtNzhpnwBXYZ+4KD An5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=47uqChEzeEajSDIQMD9mkGbRaeWz4iau82Y1pdScTdo=; b=MTmRNyXPZGsTdtuEeBC2OdwfPhcdySrS/NXdWOSsjWYFGn58HYjqMw5srdrn7QCgCX ZB48GCQNwb9uUh91yuxFFWErrQWGdnr0Ee3/IcX3UQwOvJyEHDWq39s94AfRvb7CfC9m ftnnIWUxlFyZMGOQNnP1rTMszDDcrHpUhbXugnxiOTl9SCVcpPM9TMmtkt4Bu2a+KOlW jS9ig5AqhYRF5BAwalpd+7dYILJgTTgjIJwvMH6BeFzRTzs/STluuAWVkwE68fFB4skj E2bCyb1NxfQ0eF724BJgCoULsdXEaco/9ojJy6nJ3PhcFarvltnTsewIRzEGRHzNJnND 8ALA== X-Gm-Message-State: AE9vXwN+QxpijE3cdfJw/7fxudhsdgdAtLGQUGlYUtIQr1Q4Ii16ZPvd9MAbffuZgpYA55X2 X-Received: by 10.194.147.99 with SMTP id tj3mr6975805wjb.183.1473922191522; Wed, 14 Sep 2016 23:49:51 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 190sm921194wmk.13.2016.09.14.23.49.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Sep 2016 23:49:50 -0700 (PDT) From: Thomas Monjalon To: John Ousterhout Cc: users@dpdk.org, Matthew Hall Date: Thu, 15 Sep 2016 08:49:49 +0200 Message-ID: <6167786.8dthCUDyoR@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <20160914212457.GA6972@mhcomputing.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-users] Redirect DPDK log? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 06:49:51 -0000 Hi, 2016-09-14 17:52, John Ousterhout: > On Wed, Sep 14, 2016 at 2:24 PM, Matthew Hall wrote: > > On Wed, Sep 14, 2016 at 02:08:27PM -0700, John Ousterhout wrote: > > > > > > Is there a mechanism in DPDK that can interpose on the log output? I see > > > the function rte_openlog_stream to specify a different FILE* for output, > > > but that isn't quite general enough. I'd like for a method in my > > > application to receive all of the log messages, so I can wrap them > > > appropriately and then add them to an application-specific log. Does > > such a > > > hooking mechanism exist? > > > > http://www.gnu.org/software/libc/manual/html_node/String-Streams.html > > At first I thought this approach (fmemopen) might work, but now I'm not so > sure. The problem is that fmemopen doesn't provide any sort of notification > when it adds data to the buffer. My application can use a polling approach > where it occasionally checks to see if data has been added, but this has a > serious flaw. Some of the DPDK functions, such as rte_eal_init, can panic > in the face of severe errors: they write information to the log and then > exit the application. In a situation like this, the application will not > have a chance to check for the log messages and relay them onto the > appropriate place, so the log data will be dropped and the application will > exit without leaving behind any information about what happened. > > If there were a way to intercept calls to rte_panic, then I could take that > opportunity to flush information from the fmemopen buffer, but I don't see > a way to do that...? The same issues were discussed here recently: http://dpdk.org/ml/archives/dev/2016-August/044940.html In short, yes we should have a log hook or custom handler, and yes, the panics/exit must be removed. You are welcome to work on such improvement.