On Tue, Mar 24, 2009 at 11:48:49AM +0100, Ingo Molnar wrote: > > * Roland McGrath <rol...@redhat.com> wrote: > > > Here is a trivial module to implement the seccomp guts via utrace. > > I haven't tested it at all. (AFAIK it was only ever used by > > cpushare, and that project might be defunct now.) > > > > I'm not sure what Ingo had in mind for integrating this. If it's > > just to reimplement the existing prctl interface, then this is > > about all you need--just s/_xxx// and fiddle the config et al to > > build this and not the old stuff. > > > > If the approach would be incremental, to leave the old stuff in > > place, then it might make more sense just to do a fresh new thing > > not providing that prctl interface at all. A new thing could be a > > module, and define some /sys files or whatnot for its "constrain > > me now" hook. I think a sensible thing would not require > > asm/seccomp.h at all, and instead just let the userland setup feed > > in a set of syscall numbers. It could be that flexible while still > > being quite simple so that one could audit that setup code and be > > confident it has no holes. Then future versions of cpushare (or > > whatever) would not need any special kernel support for new arch's > > nor to change the syscall set it wants to allow. > > nice! The simplification factor is already significant: > > 18 files changed, 116 insertions(+), 175 deletions(-) > > That is what we want - to remove special TIF flag uses and replace > them with utrace driven machinery. > > Another future target could be to replace TIF_SYSCALL_FTRACE [in the > latest tracing tree] with a similar utrace driven solution. > > Regarding ptrace-via-utrace. What is the plan there? Am i looking > the right branch: > > | earth4:~/linux.trees.git> git diff --stat > | linus/master..utrace/utrace-ptrace kernel/ptrace.c arch/x86/kernel/ptrace.c > | kernel/ptrace.c | 803 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++- > | 1 files changed, 794 insertions(+), 9 deletions(-) > > dc43527: Merge branch 'utrace' into utrace-ptrace > > I'd have (perhaps foolishly) expected ptrace.c to get reduced in > size and arch/x86/kernel/ptrace.c eliminated - but that does not > seem to be direction of movement. What am i missing?
Thats because the version of ptrace.c you are looking at has both the legacy implementation and the ptrace over utrace implementation with #ifdefs to separate them out. I guess Roland wanted to keep the legacy stuff around till the ptrace/utrace becomes stable enough. Ananth