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.... So there's a bunch of issues around xfs_inode.h, and this really is the first step to cleaning it all up. What currently remains in xfs_inode.h can be moved to different files - most of what is there deals with inode forks or the xfs_icdinode, and so if I move them to specific header files we ned up with an empty xfs_inode.h header. At taht point, we can stop sharing xfs_inode.h with userspace, and we can move all the kernel-only inode defintions back into xfs_inode.h, and #include all the other header files with the shared definitions directly. Userspace can do the same thing through libxfs.h.... Indeed, the underlying reason for all this separation is that in the medium term, __KERNEL__ is going to be removed from the kernel build. That's the direction being set by all the UAPI work that David Howells has been doing, and XFS is really a special snowflake when it comes to headers and userspace code sharing. Hence I'm trying to restructure the code now while we are doing lots of userspace work. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs