All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 2/3] gfs2_edit: Fix find_mtype and support gfs1 structures
Date: Fri, 25 May 2012 11:40:07 +0100	[thread overview]
Message-ID: <1337942407.2692.5.camel@menhir> (raw)
In-Reply-To: <4FBF5EAF.1070309@redhat.com>

Hi,

On Fri, 2012-05-25 at 11:27 +0100, Andrew Price wrote:
> On 25/05/12 11:07, Andrew Price wrote:
> > Fixes up find_mtype to really iterate over the metadata array and to
> > choose between gfs2 and gfs1 structures.
> >
> > Signed-off-by: Andrew Price<anprice@redhat.com>
> > ---
> >   gfs2/edit/hexedit.c |    9 +++++----
> >   1 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/gfs2/edit/hexedit.c b/gfs2/edit/hexedit.c
> > index 69d1940..8311534 100644
> > --- a/gfs2/edit/hexedit.c
> > +++ b/gfs2/edit/hexedit.c
> > @@ -813,14 +813,15 @@ int display_block_type(int from_restore)
> >   	return ret_type;
> >   }
> >
> > -static const struct lgfs2_metadata *find_mtype(uint32_t mtype)
> > +static const struct lgfs2_metadata *find_mtype(uint32_t mtype, int gfs1)
> >   {
> >   	const struct lgfs2_metadata *m = lgfs2_metadata;
> >   	unsigned n = 0;
> >
> >   	do {
> > -		if (m->gfs2&&  m->mh_type == mtype)
> > -			return m;
> > +		if (((gfs1&&  m[n].gfs1) || (!gfs1&&  m[n].gfs2))
> 
> I'm wondering if we should represent the version metadata as flags 
> instead of separate gfs1 and gfs2 fields and define some constants so we 
> can do the comparison in one go, e.g.
> 
>                  if ((m[n].versions & versions) ...
> 
> Where versions is some combination of defined constants passed into the 
> function like LGFS2_VER_1 | LGFS2_VER_2
> 
> But that has its own drawbacks I guess so I'm probably just splitting 
> hairs. What do you think?
> 
> Andy
> 
I think that makes sense. I don't remember now why I did that with a
bitfield and not flags, but it is probably better to convert it to
flags. We'll want to give them a longer name though, as everything in
the library will land up with a LGFS2_ or lgfs2_ prefix in the end,

Steve.




  reply	other threads:[~2012-05-25 10:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-25 10:07 [Cluster-devel] [PATCH 1/3] gfs2-utils: Remove references to unlinked file tag Andrew Price
2012-05-25 10:07 ` [Cluster-devel] [PATCH 2/3] gfs2_edit: Fix find_mtype and support gfs1 structures Andrew Price
2012-05-25 10:27   ` Andrew Price
2012-05-25 10:40     ` Steven Whitehouse [this message]
2012-05-25 10:07 ` [Cluster-devel] [PATCH 3/3] gfs2_edit: Clean up some magic offsets Andrew Price
2012-05-25 10:19   ` Steven Whitehouse

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=1337942407.2692.5.camel@menhir \
    --to=swhiteho@redhat.com \
    /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.