On Mon, Jun 17, 2013 at 09:02:28AM -0700, Christoph Hellwig wrote: > 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. Yup - we only need to shared the format defintions, the buffer operations and the inode fork macros. That's explicity all that is shared after my current patchset. FWIW, my current patchset does this to the xfsprogs/include directory: 43 files changed, 1541 insertions(+), 3527 deletions(-) So that will give you an idea of how much __KERNEL__ crap there is... > 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. There's plenty that can be done there, but I think the direction we need to take db in is to be closer to libxfs than it's own special little snowflake. We need to do this for the IO subsystem to add CRC validation/calculation support, so re-using anything that libxfs already provides seems sane to me... > > 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? It's not quite there yet, but getting close. I'm not sure we can get to automating it without having the same libxfs/ structure in the kernel code - it's not straight forward to identify which hunks of a patch are relevant to userspace... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
