Messages in this thread |  | | From | richardj_moore@uk ... | Date | Fri, 6 Oct 2000 10:15:45 +0100 | Subject | Re: The case for a standard kernel debugger |
| |
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/
|  |