Re: [PATCH 1/14] move user_enable_single_step & co prototypes to linux/ptrace.h

[Roland McGrath]

The original thought there was that user_enable_single_step() et al might
well be only an instruction or three on a sane machine (as if we have any
of those!), and since there is only one call site inlining would be
beneficial.  But I agree that there is no strong reason to care about
inlining it.

As to the arch changes, there is only one thought I'd add to the record.
It was always my thinking that for an arch where PTRACE_SINGLESTEP does
text-modifying breakpoint insertion, user_enable_single_step() should not
be provided.  That is, arch_has_single_step()=>true means that there is an
arch facility with "pure" semantics that does not have any unexpected side
effects.  Inserting a breakpoint might do very unexpected strange things in
multi-threaded situations.  Aside from that, it is a peculiar side effect
that user_{enable,disable}_single_step() should cause COW de-sharing of
text pages and so forth.  For PTRACE_SINGLESTEP, all these peculiarities
are the status quo ante for that arch, so having arch_ptrace() itself do
those is one thing.  But for building other things in the future, it is
nicer to have a uniform "pure" semantics that arch-independent code can
expect.

OTOH, all such arch issues are really up to the arch maintainer.  As of
today, there is nothing but ptrace using user_enable_single_step() et al so
it's a distinction without a practical difference.  If/when there are other
facilities that use user_enable_single_step() and might care, the affected
arch's can revisit the question when someone cares about the quality of the
arch support for said new facility.

So, with those caveats preserved for posteriority, all these changes
are OK with me.


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/