Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp882679ybb; Fri, 3 Apr 2020 13:41:43 -0700 (PDT) X-Google-Smtp-Source: APiQypIrWARxkr7HGUgGHp+Gw/KRQqftR0/NZSGMBJ9Lx4eLM147X3TT+37FkfRL3moek0+PyDd0 X-Received: by 2002:a4a:5747:: with SMTP id u68mr8170657ooa.32.1585946503241; Fri, 03 Apr 2020 13:41:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585946503; cv=none; d=google.com; s=arc-20160816; b=mT50clQMO7epc3FZk36dCTci2INTGkcIP/tPgOeZyufd+zJvgy6f4t2mhcp8bGCTIh rAiiBbn//6OjiJAMR61RtWb54V4/FDr5yhp8v61BI8KGNsFXBDETwIANiWSr4nI6BBOT rze2t9Xv2o0cygMKoLZt5Jg9X3cDrerQvQR1+psDMJmlap6EcXFQ9FmJycP2GjsDPBqP tGhMpn2m6vLxiYyD97GdJyM6ihAghMofczhxwlApDu07dlIyV8qBIB/omtFUrxtJtoPX qdi9GFKvRK22dcVSOVBb7r6i/rsRZQ2IPu6A7mFPlVgykIoUA5dkQJuiiXhP8Kp/SG3V IGXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=zWbWa/8rYEu0IE7xJLOCn19JbkI43RVDK1CIZXqFpck=; b=RKM663bj6BXrAU31fasxFT5tsYZfzdrkLwo6i54/MrYqwk9A6FScyLtWkbDlcEiVhL cdDqZW9kVCEWfp9RK9Do7iK4kTxWd+EQA9FOylmlSouncAn99NXwhzCszlNlCmlE9w/8 IgIGYgE+K7+gKYtd30zR1hFHXEbMiU1NOX2V+Z4K2QfvRrVoH3/MJw3932FcpoITzuig NHftfEmHkny5iuTCY7I59ddBlngtp2M9U060ikUvYTynAHJnlnw6wlqqc6J/m5t8//5x 7sPV+j/hVddhAhUwlkijkE7ICxr2ZVLHcQ54LZp92b685fFaqdnyYDh/uQaf8TpmvE7B r0lQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=KCtSW77D; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t8si4077642ood.64.2020.04.03.13.41.30; Fri, 03 Apr 2020 13:41:43 -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; dkim=pass header.i=@kernel.org header.s=default header.b=KCtSW77D; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728348AbgDCUkk (ORCPT + 99 others); Fri, 3 Apr 2020 16:40:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:36786 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728108AbgDCUkk (ORCPT ); Fri, 3 Apr 2020 16:40:40 -0400 Received: from pali.im (pali.im [31.31.79.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A98F621D6C; Fri, 3 Apr 2020 20:40:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585946439; bh=A/b6WcEW+sgH9ELmZUWFVlvFcBJ6Y5ZwDFeJXrdljgM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KCtSW77DmOIggT9pPUwNw/yxTO2kMUimvir19ZiIiCURT6k8tIAOAnJeo20VJE6PJ 8TneIQB00aX2wLWdofO3lisn97vK/2swAHw2d1a9lPIq3aoEoVBRnd/nR2fnU1550R fB84Qety3Ov5CLHFyr/lEOEBm1MRkZajQBFLSS4w= Received: by pali.im (Postfix) id 9DB575DE; Fri, 3 Apr 2020 22:40:37 +0200 (CEST) Date: Fri, 3 Apr 2020 22:40:37 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: "Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp" Cc: "'linux-fsdevel@vger.kernel.org'" , "'linux-kernel@vger.kernel.org'" , "'namjae.jeon@samsung.com'" , "'sj1557.seo@samsung.com'" , "'viro@zeniv.linux.org.uk'" Subject: Re: [PATCH 1/4] exfat: Simplify exfat_utf8_d_hash() for code points above U+FFFF Message-ID: <20200403204037.hs4ae6cl3osogrso@pali> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 03 April 2020 02:18:15 Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp wrote: > > I guess it was designed for 8bit types, not for long (64bit types) and > > I'm not sure how effective it is even for 16bit types for which it is > > already used. > > In partial_name_hash (), when 8bit value or 16bit value is specified, > upper 8-12bits tend to be 0. > > > So question is, what should we do for either 21bit number (one Unicode > > code point = equivalent of UTF-32) or for sequence of 16bit numbers > > (UTF-16)? > > If you want to get an unbiased hash value by specifying an 8 or 16-bit value, Hello! In exfat we have sequence of 21-bit values (not 8, not 16). > the hash32() function is a good choice. > ex1: Prepare by hash32 () function. > hash = partial_name_hash (hash32 (val16,32), hash); > ex2: Use the hash32() function directly. > hash + = hash32 (val16,32); Did you mean hash_32() function from linux/hash.h? > > partial_name_hash(unsigned long c, unsigned long prevhash) > > { > > return (prevhash + (c << 4) + (c >> 4)) * 11; > > } > > Another way may replace partial_name_hash(). > > return prevhash + hash32(c,32) >