From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id E32412B8B for ; Wed, 5 Oct 2016 16:03:56 +0200 (CEST) Received: from lfbn-1-5996-232.w90-110.abo.wanadoo.fr ([90.110.195.232] helo=[192.168.1.13]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1brmqf-0001dJ-5r; Wed, 05 Oct 2016 16:07:05 +0200 To: "Montorsi, Francesco" , "dev@dpdk.org" References: <32054c5dd466431ebf99d84641c6313a@bilemail1.empirix.com> <4b3ed268f2584b4aaf251ba39f8c90bf@bilemail1.empirix.com> <348c536dca594a3fbd38137e2a5a29aa@bilemail1.empirix.com> From: Olivier Matz Message-ID: <2a0d7232-fe5b-60a1-616d-84fc9448f050@6wind.com> Date: Wed, 5 Oct 2016 16:03:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <348c536dca594a3fbd38137e2a5a29aa@bilemail1.empirix.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Proposal: enable redirection of DPDK logs from the user app 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: Wed, 05 Oct 2016 14:03:57 -0000 Hi Francesco, On 10/05/2016 03:26 PM, Montorsi, Francesco wrote: > Hi Olivier, > >> On 10/04/2016 02:28 PM, Montorsi, Francesco wrote: >>> Yes, but to be honest, that seems a troublesome solution for something >>> as easy as logging a string; e.g. by using fopencookie() approach, you >>> don't have the concept of "log message", you just provide a function >>> that must write a block of bytes somewhere. >>> Typically instead, you need to know where a log message starts and >>> ends, to e.g., add prefixes/postfixes to it. >> >> I'm not sure that true if you call setbuf(log_stream, NULL). >> >> In that case, it looks easy to prefix / postfix messages with a fopencookie >> callback like: >> >> /* example on stdout */ >> ssize_t >> simple_write(void *c, const char *buf, size_t size) { >> ssize_t ret1, ret2, ret3; >> >> ret1 = fwrite("<", 1, 1, stdout); >> if (ret1 == 0) >> return 0; >> ret2 = fwrite(buf, size, 1, stdout); >> if (ret2 == 0) >> return 0; >> ret3 = fwrite(">", 1, 1, stdout); >> if (ret3 == 0) >> return 0; >> return ret1 + ret2 + ret3; >> } >> > I didn't know about setbuf()... but are we sure that in this way the simple_write() function will always receive a full string? I mean: in the manpage for setbuf() it says: > > "... When the first I/O operation occurs on a file, malloc(3) is called, and a buffer is obtained. .... If the argument buf is NULL, only the mode is affected; a new buffer will be allocated on the next read or write operation." > > But: is it true that 1 write operation corresponds to 1 vfprintf() call? Maybe if you have a "long" a single vfprintf() call may translate to several simple_write() calls... I don't know honestly. I did a quick test with a fixed version of simple_write(): ssize_t simple_write(void *c, const char *buf, size_t size) { ssize_t ret1 = -42, ret3 = -42; ssize_t ret = 0; ret1 = fwrite("<", 1, 1, stdout); if (ret1 == 0) goto ret; ret = fwrite(buf, 1, size, stdout); if (ret != size) goto ret; ret3 = fwrite(">", 1, 1, stdout); if (ret3 == 0) goto ret; ret: /* printf("ret=%d ret1=%d ret3=%d\n", (int)ret, (int)ret1, (int)ret3); */ return ret; } It looks like transmitting a string bigger than BUFSIZ (8192) induces several calls to simple_write(). For smaller calls, it seems there is no split (1 printf = 1 simple_write). Of course, this is a just test and not a proof :) I think we would have a similar issue with the other approach. For me, the current API looks ok, however let's see the opinion of the maintainer that could be different of mine. In any case, thank you for proposing enhancements. Regards, Olivier