From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1a8u20-00083G-5b for mharc-grub-devel@gnu.org; Tue, 15 Dec 2015 13:09:00 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8u1u-0007ug-0f for grub-devel@gnu.org; Tue, 15 Dec 2015 13:08:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8u1p-0001FI-V4 for grub-devel@gnu.org; Tue, 15 Dec 2015 13:08:53 -0500 Received: from mail.kernel.org ([198.145.29.136]:46135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8u1p-0001F1-PC for grub-devel@gnu.org; Tue, 15 Dec 2015 13:08:49 -0500 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7C607203B7; Tue, 15 Dec 2015 18:08:48 +0000 (UTC) Received: from localhost (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D926A203A9; Tue, 15 Dec 2015 18:08:42 +0000 (UTC) Date: Tue, 15 Dec 2015 10:08:43 -0800 From: Jaegeuk Kim To: Andrei Borzenkov Subject: Re: [f2fs-dev] [PATCH v4] F2FS support Message-ID: <20151215180843.GA60269@jaegeuk.local> References: <1427185140-41120-1-git-send-email-jaegeuk@kernel.org> <20150403224908.GB25673@jaegeuk-mac02.mot.com> <20151119212824.GA11666@jaegeuk.local> <566E7DAA.4010202@gmail.com> <20151215003421.GD48918@jaegeuk.local> <566FD090.1080906@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <566FD090.1080906@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Virus-Scanned: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 198.145.29.136 Cc: The development of GNU GRUB , linux-f2fs-devel@lists.sourceforge.net X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 18:08:59 -0000 On Tue, Dec 15, 2015 at 11:34:24AM +0300, Andrei Borzenkov wrote: > 15.12.2015 03:34, Jaegeuk Kim =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > Change log from v3: > > o add grub_test_bit_le() > ... >=20 > > + > > +static inline int > > +grub_f2fs_test_bit_le (int nr, const grub_uint8_t *addr) > > +{ > > + const grub_int32_t *p =3D (const grub_int32_t *)addr; > > + > > + nr =3D nr ^ 0; >=20 > It does nothing. Ah, right. >=20 > > + > > + return p[nr >> 5] & (1 << (nr & 31)); > > +} >=20 > Well, you still miss the point - if you are working with integers you > must shift differently depending on whether we are running big or littl= e > endian. I just thought that it would be okay to bypass 32bits and then check its = target location, since we know it is LE. Indeed, I was wrong that your concern was this line will be converted to = BE when CPU loads this 32-bit value. > But as I mentioned before, we know that bitmap is little endian so we > can work with bytes and be independent of byte order. Could you test if > this works for you: >=20 > static inline int > grub_f2fs_test_bit_le (int nr, const grub_uint8_t *addr) > { > return addr[nr >> 3] & (1 << (nr & 7)); > } Actually, I tested this before, but I got somehow failure, so tried this = one. Once I've checked bitmap contents in more details, I realized that this s= hould be a correct way; I confirmed that this has no problem. I'll send another patch. Thank you so much,