On Thu, Jun 13, 2013 at 11:14:14AM +1000, Dave Chinner wrote: > On Wed, Jun 12, 2013 at 07:05:19AM -0700, Christoph Hellwig wrote: > > On Wed, Jun 12, 2013 at 08:22:38PM +1000, Dave Chinner wrote: > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > > > The core xfs inode operations such as locking, allocation, reading > > > and writing are not shared with userspace. However, much of the > > > remaining internal inode code such as the incore extent tracking and > > > formatting is. Split the XFS inode operations out into a new > > > xfs_inode_iops.c file to minimise the differences between the files > > > shred with userspace. > > > > Having struct xfs_inode in an xfs_inode_ops.h file while xfs_inode.h > > is still around strikes me as extremely odd. > > Consider it a first step in a longer process.... > > > It seems like icdinode > > should be in xfs_inode_item.h as is part of the log format primarily. > > Yes, I've definitely been looking at that, because xfs_inode_item.h is > shared with userspace and there are some issues with cyclic > inclusion and definitions in userspace based around the fact that > the icdinode is defined in xfs_inode.h and so needs to be included > before the struct xfs_inode is defined in include/libxfs.h. Yet > there is static inline code in xfs_inode.h that needs to know the > structure of the struct xfs_inode.... And this is where it gets sticky. The xfs_inode_ops.h header has a dependency on struct xfs_icdinode. Moving that to xfs_inode_item.h means that we now have a dependencies of: xfs_inode_ops.h requires xfs_inode_item.h requires: xfs_trans.h requires: xfs_log.h which are new. And it also introduces a circular dependency as xfs_inode_item.h has a dependency on the struct xfs_inode already being defined, so it can't be included before struct xfs_inode is defined..... As it is, xfs_inode_item.h still has a section under #ifdef __KERNEL__. It's the section dealing with the struct inode_log_item, and all the other logitem header files have similar kernel only sections. libxfs has it's own definitions for these structures, so what we've got here is the shared on-disk log format definitions and kernel-only log item definitions sharing the same files in the kernel tree. 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.... The header files in XFS have never been properly sorted out - it's about time we cleaned up this mess ;) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
