> This kind of info should have been 1) emitted a month ago, in the
> middle of the development window, 2) have been part of the
> submission ('why do we want it' 'what will be the future benefit?').
Well, we are where we are. I don't really know what kind of lack
you see in having said what its future benefits will be. We have
talked out the wazoo about what utrace is for.
I also really don't understand the resistance to a new thing in a
new config option that depends on EXPERIMENTAL, and having the
smaller users bang on it and fix it in the tree for a while.
You seem now to be saying that the gating event would be rewriting
ptrace unconditionally to require utrace, and do that way early
before any other hashing out of utrace in the tree. That just seems
wildly nuts to me and I am confused about why you like the idea.
We have a new thing to shake out, so let's break a crucial feature
so that people uninterested in the new stuff can be stuck with new
bugs and regressions as early as possible! What? Did I miss a memo?
How is that the prized incrementalism that we hear so much about?
Isn't "ptrace works, we need ptrace, don't break ptrace until you're
sure you won't be breaking ptrace" what every sane user wants?
You know damn well that I am 198% for the wholesale replacement of
ptrace. (We hates the ptrace!) But that is a big lump to put in
first, and to delay every other line of development behind. Why
doesn't utrace deserve a period as EXPERIMENTAL before we force it
onto everyone's critical path?
If rewriting everything early on to use the new thing is such the
great plan, why didn't you rewrite dmesg to use ftrace ring buffers
before putting them in? (It's not a serious question, but I hope
you recognize that the ptrace question sounds about as ludicrous to
me as that one does to you.)
Why is it OK to have kprobes with no in-tree users, but not utrace?
I think you get the gist of the sort of mismatch I'm perceiving
between your remarks about utrace and the rest of reality. I don't
need the answers that would reconcile my experiences of reality.
We just need to find the way forward that is actually going to happen.
> I'm asking trivial and stupid looking followup questions, to help
> construct that kind of high level information. If it annoys you i
> can stop.
Keep asking stupid questions and I'll keep giving stupid answers.
The only thing that would annoy me is progress being prevented by
mutual lacks of understanding.
> yeah, no big reduction potential there.
Look, you shouldn't expect size reduction from cleaning up the generic
ptrace code either. The old ptrace is "simple", deceptively simple,
because it just relies on ruining all sorts of things to deliver what was
easy to kludge ages ago. We're going to have something cleaner, better,
less intrusive, and not so limited (in ways like preventing any possibility
of other user debugging facilities being implemented)--not smaller.
Thanks,
Roland
