From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
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)
Date: Fri, 9 May 2014 00:29:42 -0700 [thread overview]
Message-ID: <20140509072942.GB7882@infradead.org> (raw)
In-Reply-To: <20140506090056.GH5421@dastard>
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
to:
fs/xfs/shared
fs/xfs/include
in the kernel
libxfs/shared
libxfs/include
in userspace
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-05-09 7:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 7:18 [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8 xfs
2014-05-06 7:59 ` [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) Dave Chinner
2014-05-06 8:37 ` Christoph Hellwig
2014-05-06 9:00 ` Dave Chinner
2014-05-09 7:29 ` Christoph Hellwig [this message]
2014-05-09 21:45 ` Dave Chinner
2014-05-06 8:43 ` Christoph Hellwig
2014-05-06 9:05 ` Dave Chinner
2014-05-07 14:48 ` Brian Foster
2014-05-07 22:47 ` Dave Chinner
2014-05-08 1:12 ` Dave Chinner
2014-05-08 12:02 ` Brian Foster
2014-05-08 12:54 ` Christoph Hellwig
2014-05-08 13:45 ` Brian Foster
2014-05-08 21:21 ` Dave Chinner
2014-05-09 7:21 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140509072942.GB7882@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox