lkml.org 
[lkml]   [2009]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.




\
 
 \ /
  Last update: 2009-02-12 16:29    [from the cache]
©2003-2011 Jasper Spaans