> How complicated would it be to have a simple XFS reading program?
> Would this be an involved process? or something trivial?
> The reason I am asking is because of programs like grub and milo,
> that actually read the filesystem to find the kernel (instead of
> building a block map like lilo), and they would need updating before XFS
> could take over as the primary filesystem for linux. ( A big goal, but
> if the current XFS is of pre-beta quality, I can't wait for the actual
> release )
> (Flames may be sent directly, I like having one really good mailing list
> out there)
If you mean actually do the mapping from a path name to an inode and
then get the file blocks without kernel support, then the amount of code
involved is somewhat large - given the potential meta-data structures
you might have to read to traverse a directory and then read in extents
to figure out where the disk blocks are.
There is also the issue of dealling witha filesystem which needs recovery
running on it - the meta-data may not be consistent until that happens.
However, ignoring the latter problem, take a look at the libsim library
in cmd/xfs/sim/src - this is the XFS code built in user space for use
by commands. There is still not enough code here - none of the
user space tools do path name traversal, so the lookup code is not compiled
in user space, although it would be possible to add this.
However, given an inode number xfs_iget() gets you an inode, and xfs_bmapi
retuns a mapping of file offsets to disk block numbers.
xfs_logprint in cmd/xfs/logprint is probably the simplest user space
command which opens a filesystem from user space - it would give
you the infrastructure to make the calls to open the filesystem.
p.s. the xfs_bmap command contains an example of how to get the disk
block locations for file data out of the kernel - I suspect this is
what lilo would have to use.