Ingo Molnar wrote:
* JANAK DESAI <[email protected]> wrote:
To answer Ingo's question, we did look at other flags when I started.
However, I wanted to keep the system call simple enough, with atleast
namespace unsharing, so it would get accepted. In the original
discussion on fsdevel, unsharing of vm was mentioned as useful so I
added that in addition to namespace unsharing.
i think the only sane way to do this is to support unsharing for all
flags. Internally (i.e. in the patch-queue) it can still be structured
in a finegrained way, but in terms of exposing it to applications, it
should be an all or nothing solution i think.
Ingo
yes, I understand that now. I am currently restructuring the code based
on Al Viro's
post. The system call will ..
* accept all flags
* check for illiegal combination of flags and return -EINVAL
* check for implied missing flags and silently force them
* for each flag, call a corresponding unshare function. The flag
specific unshare function will
* return -EINVAL if the structure is being shared but the
corresponding unsharing code is not
implemented yet
* return success and pass back a pointer to a newly allocated and
duplicated structure if the
structure is being shared and the unshare code is implemented
for that flag
* return success and pass back a null pointer if the structure is
not being shared to begin with
* return -ENOMEM or appropriate error if there is a failure in
allocating/duplicating the structure
* Error returns will appropriately cleanup previously duplicated
structures and return with an error
from the syscall
* If no errors, then after going through all flags, we will be left
with appropriate new structures.
* acquire appropriate (task_lock) locks and update current task
struct with non-null, duplicated,
structures
* relinquish locks and return success from the syscall
This will allow us to incrementally add unshare functionality for
different flags without requiring
and changes to apps.
Please let me know if you see any gotchas in the above.
-Janak
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
