Completely agree - co-operation+integration is the order of the day. They
other thing I didn't mention was that the GKHI was substantially coded
before we discovered your hook capability. Part of the GKHI is also to
allow hooks to be dynamicaly defined i.e. to allow kernel modules to
declare hooks themselves, though I haven't yet implemented that - the
design is done. The MP complient remark refers to the fact that the hook
mechanism must work under MP. Our hooks are implemented by modifying code
dynamically - that has certain serialisation requrements: you need to
ensure that other processors see a consistent view of memory, which means
that you need to stop them while you're change code dynamically and also
flush their I-fetch caches. There are some very odd (H/W) behavious that
can occur with self-modifying code if the appropriate measures are not
taken.
Our uniprocessor version of GKHI is being tested as I write. We hope to
release it in the next couple of weeks. As soon as we are happy with it I
will send you a copy so you can evaluate it against you hook methodology
and we can see what ecconomies can be established.
And talking further of co-operation. I'd like to make DProbes drive your
trace facility. Did you see the announcement post I sent to LTT? The idea
is that DProbes is an enabler for other RAS facilities. We can dynamically
insert a probe anywhere into memory (user and kernel) without the need for
re-compilation of the source. From the RPN program that's driven by the
probe event handler we can initiate other facilities such as entering SGI's
kernel debugger or invoking Crash Dump or forcing a core dump. Now, DProbes
came from OS/2 and was called dynamic trace. Its original purpose was to
implement tracepoints on the fly. We can still do that with DProbes,
provided we have a tracing mechanism we can feed into. That's where you
come in. Can you provide an interface we can call from kernel space to log
a trace event with a variable length buffer?
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
Karim Yaghmour <karym@opersys.com> on 06/10/2000 09:16:12
Please respond to Karim Yaghmour <karym@opersys.com>
To: Richard J Moore/UK/IBM@IBMGB
cc: linux-kernel@vger.kernel.org
Subject: Re: The case for a standard kernel debugger
Hello Richard,
Part of your analysis is correct. The hooks were designed to take care of
static tracepoints only. That said, dynamic allocation of event IDs was
next on my list and the hooking mechanism would have been modified
consequently.
As for "multiple exits registered per hook", if you mean that you can have
more
than one function called back for each event, then this is already
possible.
The other items you mention such as atomicity and prioritization seem
interesting
indeed, although I am not sure what you mean by MP compliant as the only
thing that stops the current generalized hooking mechanism to be MP
compliant
is the insertion of correct locks during callback registration.
Please understand that the purpose wasn't to discredit your work, but
rather
to stop duplication of work as efforts could be deployed elsewhere. I think
that your work and the work already done on LTT can be brought together in
a way that would profit all. This is what I was hinting to towards the end
of the posting. It was an invitation more than anything else.
Apart from the hooking mechanism, there were other items which I mentioned
that merit discussion, such as the ability to enable dynamic probes to log
events in normal LTT traces or the event-driven state machine engine.
Hence,
if you are interested in joining forces to further enhance probing and
tracing
capabilities in Linux, I think this would be a good opportunity.
Best regards
Karim
richardj_moore@uk.ibm.com wrote:
>
> Yes, we looked at that and it didn't seem to provide the generality we
> needed - multipe exits registered per hook, ability to arm a set of hooks
> atomically, ability to prioritise dispatching order of a hook exit, MP
> complient. I may be wrong but the Linux Trace Toolkit hooks like like
they
> were specifically designed to cater for inserting static tracepoints into
> the kernel.
>
> Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
>
> http://oss.software.ibm.com/developerworks/opensource/linux
> Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
> IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
--
===================================================
Karim Yaghmour
karym@opersys.com
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:18 EST