On Thu, Jun 13, 2013 at 11:39:07AM +1000, Dave Chinner wrote: > i.e: > > kernel only -> kernel only -> shared with libxfs > > Once there's a clear boundary in the kernel code, > merging/simplifying stuff on either side of the boundary is easy to > do, but it's a secondary step. I'd consider this something for the > 3.12 cycle, not the upcoming 3.11 cycle. Much better. Btw, especially in inode land we should probably share even less code with userspace. Besides my old patches to kill the struct xfs_inode abuse in repair phase 7 there isn't too much use of it left. The db code uses inodes as temporary objects in the attrset code which looks everything but efficient, and the mkfs and repair code use it to create new files/directories. Not quite sure bringing in all the kernel code there makes so much sense given that we have other infrastructure for a lot of these in userspace anyway. > FWIW, now that I have the shared files in almost perfect sync, it > makes it much easier to make the change in the kernel tree, take the > patch, apply a couple of sed filters to it and then apply it > directly to the xfsprogs tree. I only have to do the work once now, > and so it's much faster to restructure the code now. I'm very happy to see this as I'd been aiming at it for a while. Any chance you can add a script to pull in kernel changes automatically while you're at it? _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
