Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2

[Roland McGrath]

> Yes, I believe that is Roland's intent.  I believe it was separated
> from the current suite of patches for staging purposes, to merge the
> most solid code up first.  The code is available from the utrace git
> tree in the utrace-ptrace branch.

More than just "staging".  The utrace-ptrace code there today is really not
very nice to look at, and it's not ready for prime time.  As has been
mentioned, it is a "pure clean-up exercise".  As such, it's not the top
priority.  It also didn't seem to me like much of an argument for merging
utrace: "Look, more code and now it still does the same thing!"

Instead, I figured we should merge utrace in a way that lets everybody beat
on it for new features and hash out details, without immediate risk of
regressions in ptrace (which are severely annoying to everyone when they
happen).  The proper clean-ups for ptrace can proceed in parallel with work
using utrace for things that are actually new and interesting, and at least
the first half of that clean-up work is orthogonal to utrace.

This seems like the normal way that new optional CONFIG_FOOBAR features
(marked EXPERIMENTAL, even) are handled.  We don't jump over ourselves to
make existing crucial code paths subject to a new subsystem that is getting
its first rounds of shake-out.


Thanks,
Roland
--
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/