From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRIzH-0006jz-3F for qemu-devel@nongnu.org; Fri, 08 Jun 2018 11:07:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRIzG-0005CC-3P for qemu-devel@nongnu.org; Fri, 08 Jun 2018 11:07:35 -0400 References: <20180606152128.449-1-f4bug@amsat.org> From: John Snow Message-ID: Date: Fri, 8 Jun 2018 11:07:27 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/11] misc: Add trailing '\n' to qemu_log() calls List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Michael Walle , Max Filippov , Michael Clark , Palmer Dabbelt , Sagar Karandikar , Bastian Koppelmann , Laurent Vivier , Aurelien Jarno , Paul Burton , Yongbok Kim , "Edgar E. Iglesias" , Alistair Francis , Antony Pavlov , QEMU Trivial , qemu-arm , qemu-ppc , QEMU Developers On 06/08/2018 06:54 AM, Peter Maydell wrote: > On 6 June 2018 at 20:43, John Snow wrote: >> so error_setg must be used WITHOUT \n and logging must happen with \n? >> >> If we're sure that's the way we want to have things laid out, we really >> ought to augment checkpatch to catch this -- because there's 0% chance >> that we'll keep it straight on our own otherwise. > > It's a historical side effect of them being basically separately > designed APIs. error_setg() takes the "give it the entire error > message" approach. logging is printf-style and gives the caller > flexibility to compose more complicated lines of logging with > multiple calls. Consistency between the two might be nice but > there are an awful lot of qemu_log calls in the codebase to check > and change to the other convention... > Well, there's a pragmatic reason against having it be uniform. If logging lets you build more complicated statements, perhaps a checkpatch /warning/ that you've omitted the newline might be nice. --js