Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
[EMAIL PROTECTED] wrote:
...
Commit from rpm (2006-04-26 17:41 CEST)
---------------
Make IPIPE_TRACE_PATHS configurable
ipipe v2.6/common/kernel/ipipe/tracer.c 1.10
ipipe v2.6/common/kernel/ipipe/Kconfig.trace 1.4
From a quick glance it appears to me you provided a nice interface to
break some stuff :). At least the explanation is not correct.
Those four paths are required to 1) always have an active path at hand
for recording, 2+3) keep the latest max or frozen path, and 4) escape
with to an alternative slot during max/frozen updates in case the
previous one is currently locked for output or whatever and cannot
become the new active path.
So, the absolute minimum is 3 when there is definitely no concurrent
usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
users may want to define their own begin/end points if
IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
use so far.
What is your idea behind it?
My idea is that 4 paths consume way too much memory and causes my
embedded ppc setup to choke at boot. The usual culprits like a bad
download address passed to u-boot and friends are not involved this
time, so until I figure out what on earth is causing this havoc, I'd
like to be able to lower this value to 2 by configuration.
Then better make IPIPE_TRACE_POINTS configurable. Also the whole
ipipe_trace_begin/end interface could be made optional so that the
number of paths could be reduced by _1_ (not more...).
Ok, I'll do that. Hopefully, this will help the boot issue too.
--
Philippe.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
