From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Wed, 15 Jan 2020 09:49:59 +0000 Subject: [Cluster-devel] [PATCH] Move struct gfs2_rgrp_lvb out of gfs2_ondisk.h In-Reply-To: References: <20200115084956.7405-1-agruenba@redhat.com> Message-ID: <62faa428-a933-4848-d897-deb038078ac3@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On 15/01/2020 09:24, Andreas Gruenbacher wrote: > On Wed, Jan 15, 2020 at 9:58 AM Steven Whitehouse 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.