[Top] [All Lists]

Re: [PATCH 00/60] xfs: patch queue for 3.11

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 00/60] xfs: patch queue for 3.11
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 20 Jun 2013 07:34:17 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130619091538.GA359@xxxxxxxxxxxxx>
References: <1371617468-32559-1-git-send-email-david@xxxxxxxxxxxxx> <20130619091538.GA359@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Jun 19, 2013 at 02:15:38AM -0700, Christoph Hellwig wrote:
> Hi Dave,
> I like this version a lot better from a quick glance.
> A few more comments:
>  - do we really want all that many separate _format.h headers?
>    I'd be really tempted to say we have just a single xfs_format.h
>    header, which should declare everything.  It's still not all that
>    large, and it would be a really good start to ease our include mess.

I don't see any problem with doing that, though I would like to keep
some of it separate - the dir2 stuff is complex enough that I would
like to keep it separate, but stuff like all the log item format
headers can be aggregated.

How about we end up with xfs_log_format.h for the log and log item
formats, xfs_da_format.h for all the dir2/da/attr format definitions,
and xfs_format.h for everything else?

>  - xfs_extent_ops.c still has that odd _ops.c name I hate because it
>    tends to imply it's an implementation of some ops vector.  How about
>    xfs_alloc_util.c to go with the other _util name you added?

Yup, sounds reasonable. sed can sort that one out.

>  - any chance to reorder the inode.c split so that stuff doesn't get
>    move around multiple times?

I was waiting for that question - I have been considering doing that
but I've been putting it off because it is a fair bit of shuffling
that I'd have to do from scratch. Sounds like another vote for :redo


Dave Chinner

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