[Cluster-devel] [PATCH 1/8] Import linux/gfs2_ondisk.h

Andreas Gruenbacher agruenba at redhat.com
Tue Apr 20 09:07:33 UTC 2021


On Tue, Apr 20, 2021 at 10:34 AM Andrew Price <anprice at redhat.com> wrote:
> On 20/04/2021 07:00, Andreas Gruenbacher wrote:
> > On Mon, Apr 19, 2021 at 10:47 PM Andrew Price <anprice at redhat.com> wrote:
> >> On 19/04/2021 20:35, Andreas Gruenbacher wrote:
> >>> Andy,
> >>>
> >>> On Mon, Apr 19, 2021 at 9:11 PM Andrew Price <anprice at redhat.com> wrote:
> >>>> diff --git a/gfs2/include/gfs2_ondisk.h b/gfs2/include/gfs2_ondisk.h
> >>>> new file mode 100644
> >>>> index 00000000..fc948f89
> >>>> --- /dev/null
> >>>> +++ b/gfs2/include/gfs2_ondisk.h
> >>>
> >>> any reason why this file shouldn't be at gfs2/include/linux/gfs2_ondisk.h?
> >>
> >> I didn't feel it was needed, but it does have the benefit of making sure
> >> we're not picking up the system linux/gfs2_ondisk.h when we #include
> >> <gfs2_ondisk.h> and it shows clearly that we're not trying to.
> >
> > Well, we have "-I$(top_srcdir)/gfs2/include" in CPPFLAGS so
> > gfs2/include/linux/types.h is picked up by <linux/types.h>. We already
> > rely on that working. So gfs2/include/linux/gfs2_ondisk.h would be
> > picked up by <linux/gfs2_ondisk.h> already anyway.
>
> So, what would be the advantage of having gfs2_ondisk.h in
> gfs2/include/linux/? I put types.h in that directory because I didn't
> want to change the #include statement, but I didn't see a reason to put
> gfs2_ondisk.h in there.

It's more consistent if the definitions are always included as
<linux/gfs2_ondisk.h> by the kernel and by all user-space programs.

Andreas




More information about the Cluster-devel mailing list