cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] Move struct gfs2_rgrp_lvb out of gfs2_ondisk.h
Date: Wed, 15 Jan 2020 15:43:22 +0000	[thread overview]
Message-ID: <390a75f4-50ba-ae19-c802-f2e3d0232350@redhat.com> (raw)
In-Reply-To: <d7d86bca-522a-48f5-bee3-bae50cd04485@redhat.com>

On 15/01/2020 08:58, Steven Whitehouse wrote:
> Hi,
> 
> On 15/01/2020 08:49, Andreas Gruenbacher wrote:
>> There's no point in sharing the internal structure of lock value blocks
>> with user space.
> 
> The reason that is in ondisk is that changing that structure is 
> something that needs to follow the same rules as changing the on disk 
> structures. So it is there as a reminder of that,

Perhaps some eye-catching code comments would suffice? Defining it in a 
uapi header does sort-of communicate that it's ok to use in userspace, 
whereas just having the structs in close proximity doesn't really 
communicate that they should be updated in sync.

Andy

> 
>>
>> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
>> ---
>> ? fs/gfs2/glock.h????????????????? |? 1 +
>> ? fs/gfs2/incore.h???????????????? |? 1 +
>> ? fs/gfs2/rgrp.c?????????????????? | 10 ++++++++++
>> ? include/uapi/linux/gfs2_ondisk.h | 10 ----------
>> ? 4 files changed, 12 insertions(+), 10 deletions(-)
>>

> 
> Steve.
> 
>> diff --git a/fs/gfs2/glock.h b/fs/gfs2/glock.h
>> index b8adaf80e4c5..d2f2dba05a94 100644
>> --- a/fs/gfs2/glock.h
>> +++ b/fs/gfs2/glock.h
>> @@ -306,4 +306,5 @@ static inline void glock_clear_object(struct 
>> gfs2_glock *gl, void *object)
>> ????? spin_unlock(&gl->gl_lockref.lock);
>> ? }
>> +
>> ? #endif /* __GLOCK_DOT_H__ */
>> diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h
>> index b5d9c11f4901..5155389e9b5c 100644
>> --- a/fs/gfs2/incore.h
>> +++ b/fs/gfs2/incore.h
>> @@ -33,6 +33,7 @@ struct gfs2_trans;
>> ? struct gfs2_jdesc;
>> ? struct gfs2_sbd;
>> ? struct lm_lockops;
>> +struct gfs2_rgrp_lvb;
>> ? typedef void (*gfs2_glop_bh_t) (struct gfs2_glock *gl, unsigned int 
>> ret);
>> diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
>> index 2466bb44a23c..1165627274cf 100644
>> --- a/fs/gfs2/rgrp.c
>> +++ b/fs/gfs2/rgrp.c
>> @@ -46,6 +46,16 @@
>> ? #define LBITSKIP00 (0x0000000000000000UL)
>> ? #endif
>> +struct gfs2_rgrp_lvb {
>> +??? __be32 rl_magic;
>> +??? __be32 rl_flags;
>> +??? __be32 rl_free;
>> +??? __be32 rl_dinodes;
>> +??? __be64 rl_igeneration;
>> +??? __be32 rl_unlinked;
>> +??? __be32 __pad;
>> +};
>> +
>> ? /*
>> ?? * These routines are used by the resource group routines (rgrp.c)
>> ?? * to keep track of block allocation.? Each block is represented by two
>> diff --git a/include/uapi/linux/gfs2_ondisk.h 
>> b/include/uapi/linux/gfs2_ondisk.h
>> index 2dc10a034de1..4e9a80941bec 100644
>> --- a/include/uapi/linux/gfs2_ondisk.h
>> +++ b/include/uapi/linux/gfs2_ondisk.h
>> @@ -171,16 +171,6 @@ struct gfs2_rindex {
>> ? #define GFS2_RGF_NOALLOC??? 0x00000008
>> ? #define GFS2_RGF_TRIMMED??? 0x00000010
>> -struct gfs2_rgrp_lvb {
>> -??? __be32 rl_magic;
>> -??? __be32 rl_flags;
>> -??? __be32 rl_free;
>> -??? __be32 rl_dinodes;
>> -??? __be64 rl_igeneration;
>> -??? __be32 rl_unlinked;
>> -??? __be32 __pad;
>> -};
>> -
>> ? struct gfs2_rgrp {
>> ????? struct gfs2_meta_header rg_header;
> 



      parent reply	other threads:[~2020-01-15 15:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15  8:49 [Cluster-devel] [PATCH] Move struct gfs2_rgrp_lvb out of gfs2_ondisk.h Andreas Gruenbacher
2020-01-15  8:58 ` Steven Whitehouse
2020-01-15  9:24   ` Andreas Gruenbacher
2020-01-15  9:49     ` Steven Whitehouse
2020-01-15 13:19       ` Bob Peterson
2020-01-15 15:26         ` Andrew Price
2020-01-15 15:43   ` Andrew Price [this message]

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=390a75f4-50ba-ae19-c802-f2e3d0232350@redhat.com \
    --to=anprice@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).