lkml.org 
[lkml]   [2008]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [patch -mm 0/4] mqueue namespace
    Cedric Le Goater <clg@fr.ibm.com> writes:

    > Hello !
    >
    > Here's a small patchset introducing a new namespace for POSIX
    > message queues.
    >
    > Nothing really complex a part from the mqueue filesystem which
    > needed some special care

    This looks stalled. I have a brainstorm that might takes a totally
    different perspective on things.

    The only reason we don't just allow multiple mounts of mqueuefs to
    solve this problem is because there is a kernel syscall on the path.

    If we just hard coded a mount point into the kernel and required user
    space to always mount mqueuefs there the problem would be solved.

    hard coding a mount point is unfortunately violates the unix rule
    of separating mechanism and policy.

    One way to fix that is to add a hidden directory to the mnt namespace.
    Where magic in kernel filesystems can be mounted. Only visible
    with a magic openat flag. Then:

    fd = openat(AT_FDKERN, ".", O_DIRECTORY)
    fchdir(fd);
    umount("./mqueue", MNT_DETACH);
    mount(("none", "./mqueue", "mqueue", 0, NULL);

    Would unshare the mqueue namespace.

    Implemented for plan9 this would solve a problem of how do you get
    access to all of it's special filesystems. As only bind mounts
    and remote filesystem mounts are available. For linux thinking about
    it might shake the conversation up a bit.

    Eric


    \
     
     \ /
      Last update: 2008-06-20 05:13    [W:3.487 / U:0.388 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site