Re: [PATCH 4/5] xfs_repair: don't ASSERT on corrupt ftype

From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>, xfs@oss.sgi.com
Subject: Re: [PATCH 4/5] xfs_repair: don't ASSERT on corrupt ftype
Date: Mon, 8 Sep 2014 16:23:22 +1000	[thread overview]
Message-ID: <20140908062321.GA20518@dastard> (raw)
In-Reply-To: <540D1FF1.4030601@sandeen.net>

On Sun, Sep 07, 2014 at 10:18:09PM -0500, Eric Sandeen wrote:
> On 9/7/14 10:16 PM, Dave Chinner wrote:
> >On Sun, Sep 07, 2014 at 08:02:20PM -0500, Eric Sandeen wrote:
> >>On 9/7/14 7:10 PM, Dave Chinner wrote:
> 
> ...
> 
> >>>Needs to be fixed kernel-side first.
> >>
> >>xfs_dir3_dirent_get_ftype doesn't exist in kernelspace :)
> >>
> >>bleah, why do they have different names...  Ok, will send.
> >
> >Because kernel has changed, and we need to do yet another large
> >kernel/user libxfs sync.
> >
> >I haven't found time to do that yet. Unless you want to volunteer
> >for it....
> 
> I could give it a shot.  Do you usually do it commit-by-commit,
> diff-and-edit, or a big copy?

This one is going to need multiple phases, and in a moment you're
going to understand what all functions called into libxfs should
have a "libxfs define wrapper":

	1. sync up to kernel commit before error negation
	2. make sure all external function calls have libxfs
	   define wrappers
	3. commit error negation patch and change sign of all libxfs
	   define wrappers
	4. apply kernel libxfs rename patch and restructure
	   libxfs userspace and xfsprogs build to match
	5. continue syncing kernel changes commit by commit.

Given the scope of changes, and the fact that some of the changes
have already been applied (i.e. bug fixes, finobt changes, etc)
step #1 is not going to be a straight forward commit-by-commit.
So I'm happy to do that as a bulk commit. Steps #2 and #3 are
relatively straight forward, too, just a bit painful as we need
to be sure we don't leak negative errors.

Step #4 is the big one; we want to end up with the kernel
fs/xfs/libxfs to be identical to the xfsprogs:/libxfs/ code and so
in userspace we've got to move headers around and rejig includes and
things like that. That's one I should probably do.

And from there, step 5 should be a simple extract/sed/commit process
of pulling patch by patch from the kernel changes that touch
fs/xfs/libxfs....

So, really, the big step right now is #1...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs