[Top] [All Lists]

Re: [PATCH 19/27] xfs: consolidate xfs_vnodeops.c into xfs_inode_ops.c

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 19/27] xfs: consolidate xfs_vnodeops.c into xfs_inode_ops.c
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 17 Jun 2013 09:02:28 -0700
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130613013907.GC29338@dastard>
References: <1371032567-21772-1-git-send-email-david@xxxxxxxxxxxxx> <1371032567-21772-20-git-send-email-david@xxxxxxxxxxxxx> <20130612135916.GA28988@xxxxxxxxxxxxx> <20130613013907.GC29338@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Jun 13, 2013 at 11:39:07AM +1000, Dave Chinner wrote:
> i.e:
>       kernel only -> kernel only -> shared with libxfs
> Once there's a clear boundary in the kernel code,
> merging/simplifying stuff on either side of the boundary is easy to
> do, but it's a secondary step. I'd consider this something for the
> 3.12 cycle, not the upcoming 3.11 cycle.

Much better.

Btw, especially in inode land we should probably share even less code
with userspace.  Besides my old patches to kill the struct xfs_inode
abuse in repair phase 7 there isn't too much use of it left.

The db code uses inodes as temporary objects in the attrset code which
looks everything but efficient, and the mkfs and repair code use it to
create new files/directories.  Not quite sure bringing in all the kernel
code there makes so much sense given that we have other infrastructure
for a lot of these in userspace anyway.

> FWIW, now that I have the shared files in almost perfect sync, it
> makes it much easier to make the change in the kernel tree, take the
> patch, apply a couple of sed filters to it and then apply it
> directly to the xfsprogs tree. I only have to do the work once now,
> and so it's much faster to restructure the code now.

I'm very happy to see this as I'd been aiming at it for a while.

Any chance you can add a script to pull in kernel changes automatically
while you're at it?

<Prev in Thread] Current Thread [Next in Thread>