Hi,

On 15/01/2020 09:24, Andreas Gruenbacher wrote:
On Wed, Jan 15, 2020 at 9:58 AM Steven Whitehouse <swhit...@redhat.com> wrote:
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,
I can see a point in that. The reason I've posted this is because Bob
was complaining that changes to include/uapi/linux/gfs2_ondisk.h break
his out-of-tree module build process. (One of the patches I'm working
on adds an inode LVB.) The same would be true of on-disk format
changes as well of course, and those definitely need to be shared with
user space. I'm not usually building gfs2 out of tree, so I'm
indifferent to this change.

Thanks,
Andreas

Why would we need to be able to build gfs2 (at least I assume it is gfs2) out of tree anyway?

Steve.


Reply via email to