[Top] [All Lists]

Re: [PATCH 18/27] xfs: split out xfs inode operations into separate file

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 18/27] xfs: split out xfs inode operations into separate file
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 19 Jun 2013 06:40:11 +1000
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130617181411.GE20932@xxxxxxx>
References: <1371032567-21772-1-git-send-email-david@xxxxxxxxxxxxx> <1371032567-21772-19-git-send-email-david@xxxxxxxxxxxxx> <20130612140519.GB28988@xxxxxxxxxxxxx> <20130613011414.GB29338@dastard> <20130613080009.GL29338@dastard> <20130617155644.GA26043@xxxxxxxxxxxxx> <20130617181411.GE20932@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Jun 17, 2013 at 01:14:11PM -0500, Ben Myers wrote:
> Hey Christoph,
> On Mon, Jun 17, 2013 at 08:56:44AM -0700, Christoph Hellwig wrote:
> > On Thu, Jun 13, 2013 at 06:00:09PM +1000, Dave Chinner wrote:
> > > So what I really think needs to happen here first is similar to the
> > > dir2 header file re-org. That is, a header file to define the
> > > format, and a header file to define the in-kernel structures and
> > > APIs....
> > 
> > Yes, I think we need to do this rather sooner than later.  In fact
> > I'd feeling we need to tackle the whole header mess first before
> > splitting the .c files.  Making sure the on-disk format is in one
> > or just a few headers is the most important bit of that.
> > 
> > These days I'm actually of the opinion that we probably should be
> > even more drastic about cutting the number of headers.  For the
> > on disk format a xfs_format.h for all the regular on disk format and
> > maybe and xfs_log_format.h should be more than enough.
> I like the idea of having the entire on-disk format in just a few files.  It
> would be a nice clean up.  I don't know if splitting the .c files needs to 
> wait
> on it though.

I've got patches that separate out all shared user/kernel header
information now. They QA'd OK overnight, so I'll post them in a
short while. There's no more __KERNEL__ definitions in the code
after the patch set... 

> > But back to the _ops.c naming.  I really hate it and the best counter
> > proposals I can come up with is to add a _common postfix to every file
> > intended to be shared with userspace.
> I don't understand what you don't like about the _ops.c naming... 

I can make xfs_inode_ops.[ch] go away as xfs_inode.[ch] is no longer
shared with userspace and contain kernel-only functionality. I
didn't go as far as moving everything back into xfs_inode.[ch]
because we want to merge some of it with xfs_iops.c, some with
xfs_ialloc.c, etc...

> > Using a directly also would make
> > sense, but for some reason Kbuild always had problems with modules built
> > from multiple directories and I'm more than glad that we finally managed
> > to get rid of the subdirectories.
> but I really like the libxfs subdirectory idea.  Any idea if the Kbuild issues
> are sorted out?

No idea - I don't know the issue is.

However, if the issue has been fixed (or could be easily solved)
then it seems like there is a rough agreement on moving towards a
common shared libxfs base?


Dave Chinner

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