[Top] [All Lists]

Re: [PATCH, RFC] xfs: rename "linux-2.6" subdirectory to be simply "linu

To: Alex Elder <aelder@xxxxxxx>
Subject: Re: [PATCH, RFC] xfs: rename "linux-2.6" subdirectory to be simply "linux"
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 22 Jul 2011 10:58:42 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <1311346434.2771.17.camel@doink>
References: <201107211804.p6LI4Rvf006075@xxxxxxxxxxxxxxxxxxxxxx> <20110722143420.GE19681@xxxxxxxxxxxxx> <1311346434.2771.17.camel@doink>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Jul 22, 2011 at 09:53:54AM -0500, Alex Elder wrote:
> On Fri, 2011-07-22 at 10:34 -0400, Christoph Hellwig wrote:
> > Actually it should just go away.  It's a leftover from when we had
> > code for Linux 2.4 and Linux 2.6 in the same ptools repository. 
> So this is an admission that XFS has gone from an
> Irix-only to a Linux-only filesystem?  We have
> strayed from it but I think there is value in
> trying to separate the core platform-independent
> part of the code from the part that interfaces
> with the OS environment.

It's not Linux only, but very centered around Linux APIs.  We still
have a low-level layer that only uses library-functins like sorting
helpers, trees, etc from the generic kernel, and a higher level that
fully interacts with it.  This seems like a useful abstraction to me,
and I'd like to keep it that way (nevermind that we really have to
because of libxfs in xfsprogs).  But that border is nowhere near the
linux-2.6 directory split, and much better done using a comment in
the makefile explaining which files are shared with libxfs.  That's
what I was planning to do for my move pull request.

Note that currently the shared code doesn't even perfectly align to
files, making the libxfs resync harder than nessecary, but that's
also something on my mid-term todo list.

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