[lkml]   [2009]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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
>+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 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    [W:0.063 / U:1.296 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site