* Roland McGrath <rol...@redhat.com> wrote:
> > 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.
This has been the upstream merging principle for the past 15 years:
95% of the mainline features go there with good and immediate uses,
not with "future uses".
> 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?
I think you misunderstood my point. I never advocated the wholesale,
unconditional rewriting of ptrace. A gradual approach there seems a
must - and your approach of CONFIG_UTRACE_PTRACE seems like the way
to go, initially.
What i tried to get at is the "how will the end result look like"
qestion - because arguably a ptrace replacement will be the end
goal.
( Note, Linus might still insist on a total replacement, if he
finds the #ifdef approach too ugly. I dont talk for him and he is
usually much pickier than me. )
> 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?
Kprobes is amongst the 5% exception that proves the rule. We got
burned by kprobes somewhat - it was merged and went nowhere for
years and has maintenance overhead. (Btw., there are some in-tree
users of kprobes meanwhile - but it's still largely stale.)
Kprobes is also arguably probing the kernel purely externally - so
having it as a separate, isolated entity is somewhat understandable
- even though it's still not ideal and if it were submitted today we
would probably not merge it without actual, substantial in-tree
uses.
But utrace is not a passive probe - it is an active, functional part
of the kernel that gets built in. Utrace without a real user is like
trying to get CONFIG_SECURITY upstream without a real user. It's
generally an upstream non-starter.
Ingo
