Re: [PATCH] libxfs: make resync with the userspace libxfs easier

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Tue, Dec 24, 2019 at 12:29:54AM -0800, Christoph Hellwig wrote:
> On Mon, Dec 16, 2019 at 06:35:35PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Prepare to resync the userspace libxfs with the kernel libxfs.  There
> > were a few things I missed -- a couple of static inline directory
> > functions that have to be exported for xfs_repair; a couple of directory
> > naming functions that make porting much easier if they're /not/ static
> > inline; and a u16 usage that should have been uint16_t.
> > 
> > None of these things are bugs in their own right; this just makes
> > porting xfsprogs easier.
> 
> Instead of exporting random low-level helpers can you please look
> into refactoring repair to not require such low level access.  E.g.
> the put_ino helper seems to be mostly used for convert short form
> directories from and to the 8 byte inode format, for which we already
> have kernel helpers in a slighty different form.

We do?  I didn't find /any/ helpers to fix shortform inums and ftype.
xfs_repair directly manipulates a lot of directory structures directly
with libxfs functions.

> I'm also kinda pissed that this was rushed into mainline after -rc2
> despite not fixing anything in the kernel.  That is not how the
> development cycle is supposed to work.

Frankly, I trust you (and everyone else) to know when a kernel patchset
heading upstream is going to require a lot of non-trivial changes to
xfsprogs and to send a patchset to make whatever cleanups to xfsprogs
are necessary and then port the kernel patches.

95% of the time, the API changes are pretty minor, and Eric and I can
just figure it out between the two of us.  The directory refactoring you
sent for 5.5 turned out to involve a lot more work and I didn't want
Eric to be 100% stuck with the burden of figuring out how to apply
everything.

But maybe I should start asking submitters always to send kernel +
xfsprogs patches at the same time.  Allison's been doing that with the
deferred attr patches and it's very helpful not to have to imagine what
the userspace changes will look like.

So anyway, I am sorry for ruffling your feathers.  I am particularly bad
at handling small cleanups to smooth over xfsprogs when reviewers are
short.

--D