On Tue, Apr 20, 2021 at 10:34 AM Andrew Price <anpr...@redhat.com> wrote: > On 20/04/2021 07:00, Andreas Gruenbacher wrote: > > On Mon, Apr 19, 2021 at 10:47 PM Andrew Price <anpr...@redhat.com> wrote: > >> On 19/04/2021 20:35, Andreas Gruenbacher wrote: > >>> Andy, > >>> > >>> On Mon, Apr 19, 2021 at 9:11 PM Andrew Price <anpr...@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