[Top] [All Lists]

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS developmen

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 9 May 2014 00:29:42 -0700
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140506090056.GH5421@dastard>
References: <20140506071855.F152E7FBC@xxxxxxxxxxx> <20140506075905.GA5421@dastard> <20140506083744.GA9976@xxxxxxxxxxxxx> <20140506090056.GH5421@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, May 06, 2014 at 07:00:56PM +1000, Dave Chinner wrote:
> I did this because I'm sick of having to edit 50+ files whenever a
> single header dependency changes. There are almost all cookie cutter
> duplicates because of the dependencies - if it were code, we'd
> factor it in an instant.  I just don't see why we should treat 50
> copies of the same header includes any differently....

So let's factor it out by fixing our header mess like I started
with the format headers.  That's the real fix instead of encoding
that mess by wrapping it.

> >  - do we really need the separate include/ dir?  That always annoys
> >    me when editing code.  It makes sense for something that is a real
> >    public interface, which this is not.
> It's for simplicity of updates with the userspace code. Both
> userspace and kernel need the same code layout, and userspace
> currently has a separate include directory for all the header files
> (and they get installed that way, too). If we want to change the
> userspace source layout and commingle all the headers with the C
> code, then that's a lot more work on the userspace side (i.e. it's
> more than just pointing the include/xfs symlink to libxfs/include).
> I don't mind which approach we take - it's trivial to rework the
> patchset to place all the headers in the libxfs/ directory - I just
> took the one that matched the current userspace infrastructure...

The only ones installed are xfs_fs.h and xfs_types.h.  The first one
is special.  I'd really prefer to to make a major mess of the layout
for this.  In fact I don't even really see the need for a subdirectory
just to share the files.

> > Also is libxfs/ really the right name?  libxfs in userspace has quite
> > a bit more code than this, so maybe we should just called this "shared"
> > for the shared user/kernel code?
> I'd like to have this kernel code define libxfs/, while in userspace
> we separate out all the support code (i.e. libxfs/rdwr.c, etc) into
> a different directory that builds the userspace libraries. i.e.
> libxfs/ is a static object archive that is wrapped by the userspace
> infrastructure, just like the kernel wraps it with infrastructure to
> make it useful...

Well, libxfs is the whole think in userspace.  So even if you absolutely
want to stick to a messy hiecharical layout we could at least condens it


        in the kernel


        in userspace

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