> Roland, this is what I am going to send for review. Ok.
> 1-7 are already in -mm tree, I am sending them to simplify the review. 2-7 were already in my tracehook branch, I added 1 there too. > 8-12 doesn't change the behaviour, simple preaparations. I've merged 8-11 into my tracehook branch too. > Perhaps we should send 8-10 to akpm right now? I'm not sure whether that would more useful. It's really up to you. IMHO those are not standalone cleanups like 2-7 (and even 1) are. Those are all just specific nits for this style of incrementalism where you have both ptrace implementations compilable at the same time. Whether and how to do that is part of the whole upstream review conversation about how to merge utrace and utrace-ptrace. So to me it makes more sense to have those travel as part of that whole series. IOW, for 1-7 it seems likely these will be merged without particular controversy (or interest) as worthwhile in their own right, whereas 8-10 are like 11-13+utrace.patch in only making any sense if they are all merged together. > NOTE! This series assumes utrace.patch comes next, after utrace-ptrace. > This way we can avoid "exclude_ptrace" hacks in ptrace.c, but I am not > sure this is good idea. Up to you. No, it's really up to the upstream reviewers and gatekeepers. > Just in case, please find below your utrace.patch re-diffed against this > series, it doesn't touch ptrace.c and comes with ptrace_notify_stop() > in utrace_stop(). Ok. Thanks, Roland
