I seriously suspect that we should add
struct dentry * (silly_rename_to)(struct dentry *);
either to inode methods or to dentry ones. It would provide a negative
dentry suitable for rename()ing over it. Sane filesystems would simply
have NULL here. Sucking ones (NFS and possibly the current braindead
versions of MSDOSFS and VFAT) would provide it so that VFS could do the
right thing wrt unlink() and rename(). I don't see another decent way to
handle NFS stuff. Alternatives are *much* more kludgy. Your opinion?
Another thing worth doing: we might add build_inode_methods() that
would take a list of pairs (constant,pointer to method) and build a
struct inode_operations filling the missing entries with defaults. It can
be called when we register filesystem. Results could be used instead of
current constant tables. Rationale: look at those tables. They are full of
NULLs and are pretty unreadable. Performance penalty is minimal (trivial
function called once + one additional memory access per read_inode()). It
doesn't break any code - if fs wants to supply pointers to constant tables
it's perfectly free to do so. Oh, and it will make the thing grepable.
The same goes for superblock, file and dentry methods. BTW, easy-to-add
default methods will remove a bunch of if's in fs/{open,namei,inode,stat}.c
if all filesystems will switch to that, but that's another story.
I'm mostly done with fixes, remaining filesystems being UMSDOS
(rename is broken in several other respects; e.g. there is an interval
when lookup on target gives negative dentry) and NFS. IMHO the best way to
deal with NFS would be to make VFS aware of filesystems with sucking
semantics that require taking the target out of the way if it's opened by
somebody else. They *are* different dcache-wise, anyway.
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/