Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3670339imc; Thu, 14 Mar 2019 02:32:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqxHx/40NJxN8Lt/cnp5rG18eMv1BPHpOrhs7ebc0FhTMKJACUn6eVtan6qXaMekBwig9Yeb X-Received: by 2002:a63:e615:: with SMTP id g21mr17165569pgh.362.1552555942597; Thu, 14 Mar 2019 02:32:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552555942; cv=none; d=google.com; s=arc-20160816; b=AqlLoiyO6uxKGOmxOehLyhr3n28zjsOlYr57Qot5P0vgb6WP+58ueK6xrIHbGwc83T AufspDWMwwDAnqvJnkdym4/hEkqFPp0oB81P7Uhnn+Aa0QvB7EsWetQN63CwwgNPkuqZ edC7RN0TAWSF3j7p7IteZbN2uiwsJ7BcPl4kzGbrZMqgAJbbj9zmxERtb8ZV+4pW25Qk y3fW2X93IUqSzyPXeVsf5XKLXzQ3LFPXr37plHHHzeRjm37FPd5SbtqL3mJe+3bcJt6k UwxMH/hDG+RUcM0e/YhYpqjrhEtwwhZWy/s3rWLZMMBXGsCM786pey/Dwmk671x+kCkn ng/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=+O4mCK+xpX5aweNBd6JJqYbfRwAYkqPpGnBC4uoQ0wo=; b=b0VgokaRIJYC8jxXcOJlE8Og7Eco0lIQHNjaFSTr2apLyjqroYc96eOpkDHoZWkOG2 FSibDufZBiMJ42YxP62uVvwlzSAHjAja+zJCCRx/BQsp578+5UaartOzxG2PrS7IaVdF jkfZdl1psyBxvTgcLy99DDADr2CIalIFy/089ibOx7EABMUBYQlvihjaAKuSREubuHTP ZFGeLHzMSWQwPiQOOOKQZI9xc4lUCHwBewqjfEhan3I6HkKC1GTXdQlZ6h3UFeopzKCa FfzNwe7F2+ALWcMaN3HkLnnOUkk3xBsI35o+Xeq5+Sd7Y4OB1ggQmdwDgm4+awOqHv8J 236w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g14si12317599pfh.190.2019.03.14.02.32.07; Thu, 14 Mar 2019 02:32:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727127AbfCNJaG (ORCPT + 99 others); Thu, 14 Mar 2019 05:30:06 -0400 Received: from mga04.intel.com ([192.55.52.120]:62488 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726736AbfCNJaG (ORCPT ); Thu, 14 Mar 2019 05:30:06 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2019 02:30:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,478,1544515200"; d="scan'208";a="125383921" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by orsmga008.jf.intel.com with ESMTP; 14 Mar 2019 02:29:59 -0700 Received: from andy by smile with local (Exim 4.92) (envelope-from ) id 1h4MgY-0002mA-9a; Thu, 14 Mar 2019 11:29:58 +0200 Date: Thu, 14 Mar 2019 11:29:58 +0200 From: Andy Shevchenko To: lkml@sdf.org Cc: akpm@linux-foundation.org, daniel.wagner@siemens.com, dchinner@redhat.com, don.mullis@gmail.com, geert@linux-m68k.org, linux-kernel@vger.kernel.org, linux@rasmusvillemoes.dk, st5pub@yandex.ru Subject: Re: [PATCH 1/5] lib/sort: Make swap functions more generic Message-ID: <20190314092958.GV9224@smile.fi.intel.com> References: <20190309140653.GO9224@smile.fi.intel.com> <201903091553.x29FrfMR018600@sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201903091553.x29FrfMR018600@sdf.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 09, 2019 at 03:53:41PM +0000, lkml@sdf.org wrote: > Andy Shevchenko wrote: > > On Thu, Feb 21, 2019 at 06:30:28AM +0000, George Spelvin wrote: > >> +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > > > > Why #ifdef is better than if (IS_ENABLED()) ? > > Because CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is bool and not > tristate. IS_ENABLED tests for 'y' or 'm' but we don't need it > for something that's only on or off. There is IS_BUILTIN(), though it's a common practice to use IS_ENABLED() even for boolean options (I think because of naming of the macro). > Looking through the kernel, I see both, but #ifdef or #if defined() > are definitely in the majority: > > lib/lzo/lzo1x_compress.c:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && defined(LZO_USE_CTZ64) > lib/siphash.c:#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > lib/string.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > lib/strncpy_from_user.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > lib/zlib_inflate/inffast.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > > I see a few IS_ENABLED uses in include/crypto/ and kernel/bpf/. > > It makes no real difference; #ifdef is simpler to me. > static bool __attribute_const__ > is_aligned(const void *base, size_t size, unsigned char align) > { > unsigned char lsbits = (unsigned char)size; > #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > (void)base; > #else > lsbits |= (unsigned char)(uintptr_t)base; > #endif > return (lsbits & (align - 1)) == 0; > } > Any preference? This one looks better in a sense we don't suppress the warnings when it's not needed. > > For such primitives that operates on top of an arrays we usually append 's' to > > the name. Currently the name is misleading. > > > > Perhaps u32s_swap(). > > I don't worry much about the naming of static helper functions. > If they were exported, it would be a whole lot more important! > > I find "u32s" confusing; I keep reading the "s" as "signed" rather > than a plural. For signedness we use prefixes, for plural — suffixes. I don't see the point of confusion. And this is in use in kernel a lot. > How about one of: > swap_bytes / swap_ints / swap_longs > swap_1 / swap_4 / swap_8 longs are ambiguous, so I would prefer bit-sized types. > > Shouldn't simple memcpy cover these case for both 32- and 64-bit architectures? > > This isn't a memcpy, it's a memory *swap*. To do it with memcpy > requires: > memcpy(temp_buffer, a, size); > memcpy(a, b, size); > memcpy(b, temp_buffer, size); > > This is 1.5x as much memory access, and you have to find a large > enough temp_buffer. (I didn't think a variable-length array on > the stack would make people happy.) > > Also, although it is a predictable branch, memcpy() has to check the > alignment of its inputs each call. The reason for these helpers is > to factor that out. Makes sense. -- With Best Regards, Andy Shevchenko