[PATCH -mm 0/9] unshare system call : updated patch series

[JANAK DESAI]

The following patches represent the updated version of the proposed
new system call unshare. Patches that registered system call for
different architectures were not updated but are being resent in
the series along with the updated patches.

Changes since the first submission of this patch series on 12/12/05:
	- Patches 1, 6, 7, 8, and 9 are updated to incorporate
	  feedback from Al Viro. Changes are described in the change
	  log for each of the patches (12/13/05)

unshare allows a process to disassociate part of the process context (vm
namespace, files and fs) that was being shared with a parent.  Unshare 
is needed to implement polyinstantiated directories (such as per-user 
and/or per-security context /tmp directory) using the kernel's per-process
namespace mechanism. For a more detailed description of the justification
and approach, please refer to lkml threads from 8/8/05, 10/13/05 & 12/08/05.
                                                                                
Unshare system call, along with shared tree patches, have been in use
in our department for over month and half. We have been using them to
maintain per-user and per-context /tmp directory. The latest port to
2.6.15-rc5-mm2 has been tested on a uni-processor i386 machine.

Patches are organized as follows:

1. Patch implements system call handler sys_unshare. System call
   accepts all clone(2) flags but returns -EINVAL when attempt is
   made to unshare any shared context.
2. Patch registers system call for i386 architecture
3. Patch registers system call for powerpc architecture
4. Patch registers system call for ppc architecture
5. Patch registers system call for x86_64 architecture
6. Patch implements unsharing of filesystem information
7. Patch implements unsharing of namespace
8. Patch implements unsharing of vm
9. Patch implements unsharing of files



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/