On Wed, Jun 19, 2013 at 06:40:11AM +1000, Dave Chinner wrote:
> On Mon, Jun 17, 2013 at 01:14:11PM -0500, Ben Myers wrote:
> > Hey Christoph,
> > On Mon, Jun 17, 2013 at 08:56:44AM -0700, Christoph Hellwig wrote:
> > > On Thu, Jun 13, 2013 at 06:00:09PM +1000, Dave Chinner wrote:
> > > > So what I really think needs to happen here first is similar to the
> > > > dir2 header file re-org. That is, a header file to define the
> > > > format, and a header file to define the in-kernel structures and
> > > > APIs....
> > >
> > > Yes, I think we need to do this rather sooner than later. In fact
> > > I'd feeling we need to tackle the whole header mess first before
> > > splitting the .c files. Making sure the on-disk format is in one
> > > or just a few headers is the most important bit of that.
> > >
> > > These days I'm actually of the opinion that we probably should be
> > > even more drastic about cutting the number of headers. For the
> > > on disk format a xfs_format.h for all the regular on disk format and
> > > maybe and xfs_log_format.h should be more than enough.
> > I like the idea of having the entire on-disk format in just a few files. It
> > would be a nice clean up. I don't know if splitting the .c files needs to
> > wait
> > on it though.
> I've got patches that separate out all shared user/kernel header
> information now. They QA'd OK overnight, so I'll post them in a
> short while. There's no more __KERNEL__ definitions in the code
> after the patch set...
Cool, sounds good.
> > > But back to the _ops.c naming. I really hate it and the best counter
> > > proposals I can come up with is to add a _common postfix to every file
> > > intended to be shared with userspace.
> > I don't understand what you don't like about the _ops.c naming...
> I can make xfs_inode_ops.[ch] go away as xfs_inode.[ch] is no longer
> shared with userspace and contain kernel-only functionality. I
> didn't go as far as moving everything back into xfs_inode.[ch]
> because we want to merge some of it with xfs_iops.c, some with
> xfs_ialloc.c, etc...
> > > Using a directly also would make
> > > sense, but for some reason Kbuild always had problems with modules built
> > > from multiple directories and I'm more than glad that we finally managed
> > > to get rid of the subdirectories.
> > but I really like the libxfs subdirectory idea. Any idea if the Kbuild
> > issues
> > are sorted out?
> No idea - I don't know the issue is.
> However, if the issue has been fixed (or could be easily solved)
> then it seems like there is a rough agreement on moving towards a
> common shared libxfs base?
Yeah, it sounds like it... regardless of whether it goes into a separate
directory. I would also be good to get that old xfstest going again. Looks
like it was 040.