Date:	Thu, 10 May 2007 01:49:26 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: utrace comments

> No need to renumber.  You remove TIF_SYSCALL_EMU which is six,
> so the newly added TIF_FORCED_TF could reuse that bit.

No, that would be incorrect.  As I mentioned earlier, there are magic
semantics to bits < 16, namely that they are in _TIF_ALLWORK_MASK (and
assembly code knows implicitly that these are in the low 16 bits).
TIF_FORCED_TF must not be in _TIF_ALLWORK_MASK, hence must be >= 16.

> > Ok.  The kerneldoc stuff is new and strange to me, and I've never
> > personally experienced its benefical features.  But I've read
> > Documentation/kernel-doc-nano-HOWTO.txt now and I will try to convert all
> > my documentary comments to that style.
> 
> Thanks.  If you need some help ping me or Randy.

I've converted the comments to kerneldoc style where I could figure out how
to.  I left some unmarked comments in places I couldn't see how to get them
extracted from.  I'd appreciate any specific advice you have for the
descriptive comments as they now stand.

> Current gcc (since 3.<something>) can optimize away code under if-branches
> that are determinable at compile time, so having each architecture
> define a (possible trivial) arch_has_single_step() should be fine.

What I had in mind was whole chunks of code you might not build, including
global symbols or whole modules.  In particular, I expect to have some
utility code for executing a single copied instruction (in the style of
kprobes), which can also be implemented for machines without single-step
(see kprobes ARM port).  That could be employed to simulate single-stepping
by a tracing engine (though not without complexities and caveats, which is
why it won't be built in as the UTRACE_ACTION_SINGLESTEP support).  An
engine could support this using only machine-independent interfaces to the
aforementioned utility code, and rely on arch_has_single_step() to know
whether it needs to.  That code might be costly to build in and would not
all be dropped at compile time even if always dead at runtime, or perhaps
isn't there at all for a particular machine.  But if on that machine you
know at compile time that arch_has_single_step() will never return 0, you
don't need it.  I don't want to get too bogged down in those specifics,
because they aren't the point right now.  The only point I'm making here is
that #if really is going to be useful.

> Btw, is there a fundamental reason why an architecture would not support
> single-stepping except for a transition period of porting, i.e. are there
> real hardware limitation in any of our ports?

As I understand it, Alpha and ARM hardware in fact have no single-step feature.
There may be others.  

> > utrace_native_view is expected to be the only user of the *_view symbols.
> > I inlined it because on single-arch platforms it's just a constant return
> > and I didn't want to add another useless call frame.  I admit this is undue
> > microoptimization.  Perhaps utrace_native_view should just be non-inlined
> > and exported.
> 
> Yeah, the latter probably makes sense.

I've changed it that way now.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists