Messages in this thread | | | Date | Thu, 12 Feb 2009 16:27:14 +0100 (CET) | From | Jan Engelhardt <> | Subject | Re: [PATCHv2 1/5] VFS: DazukoFS, stackable-fs, file access control |
| |
On Tuesday 2009-02-03 20:15, John Ogness wrote:
>Patch 1: Introduces DazukoFS as a nullfs. This is the raw stackable > filesystem part of DazukoFS and does nothing except stack and > pass filesystem calls to the lower filesystem. > >Patched against 2.6.29-rc3. > >Index: linux-2.6.28/Documentation/filesystems/dazukofs.txt >=================================================================== >--- /dev/null 1970-01-01 00:00:00.000000000 +0000 >+++ linux-2.6.28/Documentation/filesystems/dazukofs.txt 2009-02-03 18:07:44.000000000 +0100 >+ >+===================== >+ MOUNTING/UNMOUNTING >+===================== >+ >+DazukoFS is typically mounted on top of an existing directory. For example, >+to stack DazukoFS on top of the /opt directory, the following mount(8) >+command can be given: >+ >+# mount -t dazukofs /opt /opt [...] >+# mount -t dazukofs /opt /mnt >+ >+When accessing files within /mnt, you will be accessing files in /opt >+(through DazukoFS). When accessing files directly in /opt, DazukoFS will not >+be involved. >+ >+THIS HAS POTENTIAL PROBLEMS!
This ought to be done better in light of the problem that one could issue `mount -t dazukofs /mnt /opt` In kernel code, I'm thinking something like
static int foofs_dothis(...) { buf = call d_path on sb->s_root call namei_lookup on buf use lookup's resulting dentry as source directory }
This assumes at least that namei_lookup will not return the new SB's dentry for the given path. Iff that works out somehow, the 'device' part in the mount command line is practically ignored like it is for like procfs.
| |