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;
>
prev 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).