From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v4] F2FS support
Date: Tue, 15 Dec 2015 10:08:43 -0800 [thread overview]
Message-ID: <20151215180843.GA60269@jaegeuk.local> (raw)
In-Reply-To: <566FD090.1080906@gmail.com>
On Tue, Dec 15, 2015 at 11:34:24AM +0300, Andrei Borzenkov wrote:
> 15.12.2015 03:34, Jaegeuk Kim пишет:
> > Change log from v3:
> > o add grub_test_bit_le()
> ...
>
> > +
> > +static inline int
> > +grub_f2fs_test_bit_le (int nr, const grub_uint8_t *addr)
> > +{
> > + const grub_int32_t *p = (const grub_int32_t *)addr;
> > +
> > + nr = nr ^ 0;
>
> It does nothing.
Ah, right.
>
> > +
> > + return p[nr >> 5] & (1 << (nr & 31));
> > +}
>
> Well, you still miss the point - if you are working with integers you
> must shift differently depending on whether we are running big or little
> 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:
>
> 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 should
be a correct way; I confirmed that this has no problem.
I'll send another patch.
Thank you so much,
WARNING: multiple messages have this Message-ID (diff)
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH v4] F2FS support
Date: Tue, 15 Dec 2015 10:08:43 -0800 [thread overview]
Message-ID: <20151215180843.GA60269@jaegeuk.local> (raw)
In-Reply-To: <566FD090.1080906@gmail.com>
On Tue, Dec 15, 2015 at 11:34:24AM +0300, Andrei Borzenkov wrote:
> 15.12.2015 03:34, Jaegeuk Kim пишет:
> > Change log from v3:
> > o add grub_test_bit_le()
> ...
>
> > +
> > +static inline int
> > +grub_f2fs_test_bit_le (int nr, const grub_uint8_t *addr)
> > +{
> > + const grub_int32_t *p = (const grub_int32_t *)addr;
> > +
> > + nr = nr ^ 0;
>
> It does nothing.
Ah, right.
>
> > +
> > + return p[nr >> 5] & (1 << (nr & 31));
> > +}
>
> Well, you still miss the point - if you are working with integers you
> must shift differently depending on whether we are running big or little
> 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:
>
> 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 should
be a correct way; I confirmed that this has no problem.
I'll send another patch.
Thank you so much,
------------------------------------------------------------------------------
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2015-12-15 18:09 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-24 8:19 [PATCH] F2FS support Jaegeuk Kim
2015-03-24 8:19 ` Jaegeuk Kim
2015-03-28 7:31 ` Andrei Borzenkov
2015-03-28 7:31 ` Andrei Borzenkov
2015-03-28 20:43 ` Jaegeuk Kim
2015-03-28 20:43 ` Jaegeuk Kim
2015-03-28 21:00 ` Andrei Borzenkov
2015-03-28 21:00 ` Andrei Borzenkov
2015-04-03 22:48 ` Jaegeuk Kim
2015-04-03 22:48 ` Jaegeuk Kim
2015-04-03 22:49 ` [PATCH v2] " Jaegeuk Kim
2015-04-03 22:49 ` Jaegeuk Kim
2015-04-29 20:48 ` [f2fs-dev] " Jaegeuk Kim
2015-04-29 20:48 ` Jaegeuk Kim
2015-04-30 3:32 ` Andrei Borzenkov
2015-04-30 3:32 ` Andrei Borzenkov
2015-05-02 17:15 ` Andrei Borzenkov
2015-05-02 17:15 ` Andrei Borzenkov
2015-05-03 6:28 ` Andrei Borzenkov
2015-05-03 6:28 ` Andrei Borzenkov
2015-05-07 14:51 ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-05-07 14:57 ` Andrei Borzenkov
2015-11-19 21:28 ` [PATCH v3] " Jaegeuk Kim
2015-11-19 21:28 ` Jaegeuk Kim
2015-12-14 8:28 ` Andrei Borzenkov
2015-12-14 8:28 ` Andrei Borzenkov
2015-12-15 0:30 ` [f2fs-dev] " Jaegeuk Kim
2015-12-15 0:30 ` Jaegeuk Kim
2015-12-15 0:34 ` [f2fs-dev] [PATCH v4] " Jaegeuk Kim
2015-12-15 0:34 ` Jaegeuk Kim
2015-12-15 8:34 ` [f2fs-dev] " Andrei Borzenkov
2015-12-15 8:34 ` Andrei Borzenkov
2015-12-15 18:08 ` Jaegeuk Kim [this message]
2015-12-15 18:08 ` Jaegeuk Kim
2015-12-15 18:14 ` [f2fs-dev] [PATCH v5] " Jaegeuk Kim
2015-12-15 18:14 ` Jaegeuk Kim
2016-01-07 19:37 ` [f2fs-dev] " Michael Zimmermann
2016-01-07 19:37 ` Michael Zimmermann
2016-01-08 19:41 ` [f2fs-dev] [PATCH v6] " Jaegeuk Kim
2016-01-08 19:41 ` Jaegeuk Kim
2016-02-22 9:25 ` [f2fs-dev] " Andrei Borzenkov
2016-02-22 9:25 ` Andrei Borzenkov
2016-02-22 18:21 ` [f2fs-dev] " Jaegeuk Kim
2016-02-22 18:21 ` Jaegeuk Kim
2016-02-22 18:25 ` [f2fs-dev] [PATCH v7] " Jaegeuk Kim
2016-02-22 18:25 ` Jaegeuk Kim
2016-03-01 19:52 ` [2.02] Re: [f2fs-dev] " Andrei Borzenkov
2016-03-01 19:52 ` Andrei Borzenkov
2016-03-02 23:20 ` Michael Zimmermann
2016-03-02 23:20 ` Michael Zimmermann
2016-03-03 21:35 ` Jaegeuk Kim
2016-03-03 21:35 ` [2.02] " Jaegeuk Kim
2016-03-03 21:36 ` [2.02] Re: [f2fs-dev] [PATCH v8] " Jaegeuk Kim
2016-03-03 21:36 ` Jaegeuk Kim
2016-08-04 17:06 ` [f2fs-dev] [2.02] " Jaegeuk Kim
2016-08-04 17:06 ` Jaegeuk Kim
2016-08-05 10:57 ` [f2fs-dev] " Andrei Borzenkov
2016-08-05 10:57 ` Andrei Borzenkov
2016-08-05 18:07 ` [f2fs-dev] " Jaegeuk Kim
2016-08-05 18:07 ` Jaegeuk Kim
2016-08-05 19:17 ` [f2fs-dev] " Michael Zimmermann
2016-08-05 19:17 ` Michael Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151215180843.GA60269@jaegeuk.local \
--to=jaegeuk@kernel.org \
--cc=arvidjaar@gmail.com \
--cc=grub-devel@gnu.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.