Matthew Helsley wrote:
Is eliminating rename such a great idea? I realize it makes the code
simpler, but doesn't it also violate the principle of least suprise by
preventing a user from mv'ing things around?
Yes, it is an interface change in that sense.
But it wasn't being correctly implemented the last time around anyway.
The rcfs rename operation was only calling fs/libfs.c:simple_rename()
without doing the following:
- change the name cached by rcfs as part of rcfs_inode_info structure
- go down the subtree, changing the cached names of all children
- callin to rbce so it can change all rules that refer to the old class
name.
Your description:
Disallow any renaming of directories/files. It is not worthwhile to add
additional complexity to deal with cached names and the effects on rules
defined in classification engines.
Where do cached names become a concern except in RBCE?
Nowhere else.
Our caching of pathnames within the CKRM core class structure was
motivated by making RBCE's lookup of these names more efficient, *given*
that we'd chosen to go with /path/to/rcfs/directory/of/class as the
namespace for CKRM classes (and allow that path to be used to id classes
in rules).
If we don't cache names in the core structure, every time rbce needs to
lookup a class, it'll need to do a vfs path walk to get the dentry
corresponding to that pathname and derive the core class pointer from
that dentry. Way too expensive and probably has locking issues.
Perhaps RBCE
ought to be changed to not use names directly except on read/write.
I don't follow. How will users refer to a class as part of a rule ?
Certainly its an option to return a handle (core class's id would be
good) to the user whenever a class is created and to use that handle as
part of rules etc. But it makes usage of /rcfs not quite as intuitive.
Overall I thought the complexity of handling renames properly wasn't
worth the benefit of the slight additional flexibility. The user (or we)
can provide a shell script that does the rename.
- creates the new named directory
- moves all members from old to new
- deletes the old directory
- recreates the affected rules in rbce with the new name (might need to
scan and store the rules affected first).
Cheers,
-Matt
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
