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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
