On 06/21/2011 10:25 AM, Oleg Nesterov wrote: > OK, I won't argue. So we need to rework utrace/ptrace in 3.0, then we > should do this again in 3.1. I'll try to do something.
I have a thought here, I'm not familiar enough with utrace internals to know whether it is a good one or not. Originally, implementing ptrace via utrace was optional - if I remember correctly there was a define that turned it off and on. One of the good things about implementing ptrace-via-utrace is that they co-existed well - you could ptrace a process that you were also using utrace on. If I remember correctly, during one of the utrace reviews, making ptrace-via-utrace optional was requested to be removed. Now with the recent ptrace changes, still implementing ptrace-via-utrace will take some work. OK, so here's my (hacky) idea: (1) Forget ptrace-via-utrace. Have utrace be a separate thing. This way the recent ptrace changes won't matter. (2) But, what about ptrace co-existing well with utrace? Make them mutually exclusive - a ptraced-process can't be utraced and a utraced-process can't be ptraced. Assuming the above is a semi-reasonable idea, it might be a lot less work than updating the ptrace-via-utrace code to handle the new ptrace changes. -- David Smith dsm...@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)
