Hi folks, As I mentioned in the in-kernel libxfs reowrk thread, there's a problem with the libxfs code being dependent on the struct xfs_mount, which is defined externally to libxfs. The series stemmed from that as a way of working out the issues with untangling the circular dependency mess. Essentially all the da code is dependent on the struct xfs-mount for directory and attribute tree configuration - block sizes, merge thresholds, etc. These all need to be defined and managed by the libxfs code itself, and the external code should just manage it. So, this patchset removes one of the dependencies from the da code by adding a geometry structure to the xfs_da_args that contains all the necessary information from the struct xfs_mount. In doing this abstraction, I realised that this is exactly the abstraction needed to do per-inode directory block size configuration rather than have it be fixed for the entire filesystem by the superblock. So the patch set also sets the ground work for that. It also opens some other interesting avenues - the directory geometry is really just a specialised data fork allocation policy structure. I'll leave the reader to follow that to it's logical conclusion.... Now, this patchset is currently only compile tested - if you try to run it, it will eat all your Precious' and then ask "Please, Sir, can I have some more?". There are things that I've noticed in later patches that need fixing in earlier patches and I've just left them with an XXX in place, so there's no need to tell me that work needs to be done to fix this ;) I am posting it, however, to demonstrate the process which I think we need to take to properly abstract the core XFS code from both the kernel glue layer and the userspace layer. I'm looking for early feedback for this in the context of the libxfs-in-kernel branch I posted a couple of days ago. I don't want to get 90% into a restructure and then have people say "No, this is wrong!". Eventually, I'd like to have the libxfs code be completely indepenent of the struct xfs_mount, and the external struct xfs_mount just hold a bunch of structures it passes to the libxfs code. It'll take quite a bit of work to get there, but if I'm going to be using libxfs as the core infrastructure of a smart block device, I don't want to carry an xfs_mount around at all.... So, flames, comments, deep thoughts, ponderings, straight jackets, and so on are all welcome! just don't try to run the code ;) Cheers, Dave. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
