Re: [RFC] Proposal for ptrace improvements

[Tejun Heo]

Hello, Denys.

On Wed, Mar 02, 2011 at 12:51:24AM +0100, Denys Vlasenko wrote:
> > Maybe it should, maybe not, but that's mostly irrelevant because the
> > described behavior is the current behavior.
> 
> This is not a good argument. We are in this discussion exactly because
> there are cases of current behavior in strace and gdb which are clearly
> wrong and which we want to change. Therefore, "it's the current
> behavior" does not automatically mean it is desired behavior.

That actually is the whole point of the proposal and the only viable
way to proceed.  We shouldn't change the kernel so that gdb somehow
magically changes its behavior to fit someone's "should"s.  We fix the
bugs and provide new features which future versions of strace and gdb
can take advantage of to implement better behavior.

So, _NO_, we don't want to make things work magically.

> > There is no
> > continue-if-not-job-control-stopped operation and we shouldn't change
> > that beneath gdb
> 
> I feel that "continue" is meant to be such operation. Currently
> it is not merely because ptrace is buggy.

Again, that's _YOUR_ feeling.  I feel differently and what you or I
feel ultimately is irrelevant because that's a very user-visible
behavior.  We CAN'T change that.  What we can do is providing
mechanisms to userland so that they can implement what they think is
appropriate.

If gdb maintainers think cont should obey job control, fine, but
that's gdb's decision to make.  e.g. gdb can be updated to inform the
user that the tracee entered job control stop instead and ask what the
user wants to do - wait, resume the tracee or send SIGCONT, but these
decisions don't belong in the kernel and we definitely can't and
shouldn't make that happen beneath gdb.

> There is already continue-no-matter-what command in gdb:
> 
> (gdb) signal SIGCONT

Whatever, it doesn't matter.  That's not the current mode of operation
people are used to.  People expect the tracee to resume execution no
matter which condition it was in when they type cont and press enter.
That's it.

> > because otherwise not only the behavior changes
> > unexpectedly
> 
> "strace no longer breaks ^Z" is also an unexpected
> change in behavior. This doesn't mean we should avoid it,
> right?

The proposal doen't change that either.  It _PROVIDES_ ways to
implement better behavior.  It doesn't magically change the existing
behaviors.  That's the whole frigging point.

> Bottom line is: I am not trying to shoot your proposal down.
> It looks good to me.
> 
> I am only discussing it in more detail from the userspace API
> POV and from "what changes will be needed in strace and gdb?"
> and "what improvements in strace and gdb are becoming possible
> with this proposal, and how exactly to implement them there?"
> POVs.

If you were arguing "what change will be needed in userland", we
wouldn't be arguing at all.  You're arguing about changing existing
behavior beneath the current users.  If you're trying to do the
former, I gotta pull a SJ here, you're doing it wrong.

Thanks.

-- 
tejun
--
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/