On Wed, Sep 15, 2021 at 05:58:21PM -0700, Darrick J. Wong wrote: > On Thu, Sep 16, 2021 at 10:46:46AM +1000, Dave Chinner wrote: > > On Wed, Sep 15, 2021 at 04:06:51PM -0700, Darrick J. Wong wrote: > > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > > Create a mockups.h for mocked-up versions of kernel data structures to > > > ease porting of libxfs code. > > > > > > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > --- > > > include/libxfs.h | 1 + > > > libfrog/Makefile | 1 + > > > libfrog/mockups.h | 19 +++++++++++++++++++ > > > libxfs/libxfs_priv.h | 4 +--- > > > 4 files changed, 22 insertions(+), 3 deletions(-) > > > > I don't really like moving this stuff to libfrog. The whole point of > > libxfs/libxfs_priv.h is to define the kernel wrapper stuff that > > libxfs needs to compile and should never be seen by anything outside > > libxfs/... > > How did you handle this in your xfsprogs port? I /think/ the only > reason we need the mockups is to handle the perag structure in xfs_ag.h? > In that case, I guess one could simply omit the stuff below the "kernel > only structures below this line" line? I just put an #ifdef __KERNEL__ in the userspace code, like we have in userspace libxfs/xfs_btree.c for the btree split hand-off code. > In that case, can you (or anyone, really) fix libxfs-compare to be smart > enough to filter out the "#ifdef __KERNEL__" parts of libxfs from the > diff? You mean tools/libxfs-diff? I'm not sure that's a simple thing to do because of the #else cases that go along with define in xfs_btree.c. Is there really enough noise from libxfs-diff at the moment that this is actually a problem? As it is, my longer term plan it to actually properly support things like spinlocks, atomics, rcu, etc in xfsprogs via pthread and liburcu wrappers defined in include/<foo.h> that are xfsprogs wide. At that point, the wrappers in libxfs/libxfs_priv.h then simply disappear. I'd prefer we move towards proper support for these primitives rather than just rearranging how we mock them up... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
