Hi,
I've been working on making it possible to use xfstests with the in-kernel AFS
filesystem. With a few kernel patches, I've got it down to 17 failing tests
from -g quick.
Most of the remaining tests fall into a couple of classes and I wonder what
the best way to handle them is:
(1) Features that AFS doesn't support - such as ctime, device files and
fifos. I have managed to emulate ctime in the fs driver, but that leaves
mknod and mkfifo.
I've tried to modify generic/294 along the lines of generic/050 so that
it can have different comparison data depending on whether mknod exists
or not, but I can't get it to work. I've supplied a cfg file and an
alternate verified output file, but now it just says "no qualified
output" and does nothing. I can't see how it's meant to work, and README
and the stuff in doc/ doesn't help.
Should I split tests into two where, say, one part does things on regular
files, dirs and symlinks and the other does things on more exotic types,
such as fifos. generic/423 is a prime example of this.
(2) Differences in security model. Access to AFS is governed primarily by
the kerberos ticket in your keyring and is evaluated on the server (which
gives you a permissions mask that you can cache) - and not by what your
process uid/gid/grouplist say compared to the uid/gid on the file and
most of the mode bits are ignored as well.
Any thoughts on this? Should I add more _require_xxx macros for all of these
things?
Also, would there be interest in patches to automate some of this from the
fsinfo() syscall I've proposed which allows the filesystem indicate its
capabilities?
David
