Re: tracehooks changes && 2.6.32 -mm merge plans

Roland McGrath
2009-09-18T01:56:06Z

> On 09/15, Andrew Morton wrote:
> >
> > #signals-tracehook_notify_jctl-change.patch: needs changelog folding too
> > signals-tracehook_notify_jctl-change.patch
> > signals-tracehook_notify_jctl-change-do_signal_stop-do-not-call-tracehook_notify_jctl-in-task_stopped-state.patch
> > #signals-introduce-tracehook_finish_jctl-helper.patch: fold into signals-tracehook_notify_jctl-change.patch
> > signals-introduce-tracehook_finish_jctl-helper.patch
>
> I think these make sense anyway,

Agreed.

> > utrace-core.patch
> >
> > utrace. What's happening with this?
>
> (since Roland didn't reply yet)
>
> I guess this patch should be updated.

We do have a newer version now with various fixes and clean-ups.
But the current version does not play nice with ptrace (does not
even exclude ptrace any more). Without at least the ptrace
exclusion, using both utrace modules and ptrace might lead to a
confused kernel or BUG_ON hits.

Past feedback tells us that we need some in-tree users of the
utrace API to get merged too. Frank was working on such a thing,
and the IBM folks may have another such thing, but I don't know
the present status of those modules.

Oleg is working feverishly on revamping ptrace using utrace.
Other past feedback has suggested this is what people want to see
to justify utrace going in. That ptrace work is still a bit away
from being ready even for -mm submission. We're pretty sure that
we will do some more changes in the utrace core to make that work
well, so utrace merged first would be sure to get more changes
later (probably including some API differences).

Thanks,
Roland