|
|
RAS BoF Part2 - Crash Dump and Trace
This BoF continues the discussion and work that took place following the successful BoF on Trace and Dump at last year's symposium.
Trace: LTT has been undergone a considerable revamp; the most recent development being the abstraction of the relayfs from the tracing client. relayfs has the potential for being a core kernel component that could replace the private buffering schemes used by other kernel components such as printk and syslog. How should relayfs develop? What are the implications of using this scheme as a common buffering mechanism for logging? What other kernel components would benefit from migrating to relayfs? One of the outcomes of last year's BoF was the publication (on the LTT web-site) of a set of functional of goals for Trace. Is this list complete? What are the priorities and the community's needs?
Dump: lkcd has similarly undergone a considerable reconstruction since this time last year. We now have non-disruptive dump with selectable dump targets. We are working on integrating the mcore techniques with kexec for a reliable stand-alone dump. The problem for all RAS technologies is their adoption into the main kernel stream. Do we have the right design structure? Are there abstractions, similar to those of relayfs, that might make lkcd much more acceptable for inclusion into the kernel. What's the correct strategy for convincing the development community that dump and trace are good for linux and the development community?
This BoF will be lead by:
Richard J Moore, Bob Wisniewsky, Tom Zanussi, Suparna Bhattacharya - IBM LTC;
Karim Yaghmour - Opersys;
Matt Robinson - Alacritech .
|
|
