From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VExRe-0002AC-N3 for qemu-devel@nongnu.org; Thu, 29 Aug 2013 04:19:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VExRU-0002zF-HP for qemu-devel@nongnu.org; Thu, 29 Aug 2013 04:19:10 -0400 Received: from mail-pd0-f176.google.com ([209.85.192.176]:59051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VExRU-0002yz-B2 for qemu-devel@nongnu.org; Thu, 29 Aug 2013 04:19:00 -0400 Received: by mail-pd0-f176.google.com with SMTP id q10so131565pdj.7 for ; Thu, 29 Aug 2013 01:18:59 -0700 (PDT) Message-ID: <521F03EC.80908@ozlabs.ru> Date: Thu, 29 Aug 2013 18:18:52 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1376891726-26122-1-git-send-email-aik@ozlabs.ru> <1376891726-26122-2-git-send-email-aik@ozlabs.ru> <5B9725EC-8FC8-469C-8758-08EED7D4206D@suse.de> <1377564201.3819.87.camel@pasglop> <521C0567.7070400@suse.de> <1377576606.3819.100.camel@pasglop> <315B31BA-FE61-45CA-A1C1-F1E67702E5F4@suse.de> In-Reply-To: <315B31BA-FE61-45CA-A1C1-F1E67702E5F4@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 1/8] target-ppc: Add helper for KVM_PPC_RTAS_DEFINE_TOKEN List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Anthony Liguori , Paul Mackerras , =?UTF-8?B?QW5kcmVh?= =?UTF-8?B?cyBGw6RyYmVy?= , David Gibson On 08/27/2013 06:36 PM, Alexander Graf wrote: > > On 27.08.2013, at 06:10, Benjamin Herrenschmidt wrote: > >> On Tue, 2013-08-27 at 03:48 +0200, Andreas Färber wrote: >>> Also, QEMU is definitely not the only project that has higher >>> acceptance >>> criteria than patch-works-for-the-patch-author. :) >> >> There's a difference between high acceptance criteria and systematic >> bike shed painting including in some case request to turn reasonably >> meaningful identifiers into something that nobody would get :-) > > The name doesn't tell at all what the function is doing. This is even true for the kernel ioctl, but that one is in now, so it's there to stay. Heck, I even had to look up the API documentation to know whether this sets an RTAS to be handled in-kernel or in-user-space. > > Just come up with a good name and all is well. Or are you enjoying to complain on every patch review I do now? So - kvmppc_define_rtas_in_kernel() or kvmppc_define_rtas_kernel_token()? I would actually though that the very first "k" is for "Kernel" already but... -- Alexey