From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754018AbZBUHsx (ORCPT ); Sat, 21 Feb 2009 02:48:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752174AbZBUHso (ORCPT ); Sat, 21 Feb 2009 02:48:44 -0500 Received: from hera.kernel.org ([140.211.167.34]:48603 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752173AbZBUHsn (ORCPT ); Sat, 21 Feb 2009 02:48:43 -0500 Message-ID: <499FB1D8.1090601@kernel.org> Date: Sat, 21 Feb 2009 16:48:40 +0900 From: Tejun Heo User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Andrew Morton CC: rusty@rustcorp.com.au, tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com, jeremy@goop.org, cpw@sgi.com, mingo@elte.hu Subject: Re: [PATCH tj-percpu] percpu: s/size/bytes/g in new percpu allocator and interface References: <1234958676-27618-1-git-send-email-tj@kernel.org> <1234958676-27618-10-git-send-email-tj@kernel.org> <499E5BF9.1060806@kernel.org> <20090220003743.d787107b.akpm@linux-foundation.org> <499F73BD.4030105@kernel.org> <499F7836.5090608@kernel.org> In-Reply-To: <499F7836.5090608@kernel.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (hera.kernel.org [127.0.0.1]); Sat, 21 Feb 2009 07:48:23 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Andrew. Tejun Heo wrote: > Do s/size/bytes/g as per Andrew Morton's suggestion. > > Signed-off-by: Tejun Heo > Cc: Andrew Morton > --- > Okay, here's the patch. I also merged it to #tj-percpu. Having done > the conversion, I'm not too thrilled tho. size was consistently used > to represent bytes and it's very customary especially if it's a memory > allocator and I can't really see how s/size/bytes/g makes things > better for percpu allocator. Clear naming is good but not being able > to use size in favor of bytes seems a bit extreme to me. After all, > it's size_t and sizeof() not bytes_t and bytesof(). That said, I have > nothing against bytes either, so... Eeeek... I'm sorry but I'm popping this patch. It just doesn't look right. I'll add comments where appropriate that size is in bytes instead. Thanks. -- tejun