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
|