Yes, I agree with most of this. Matches exactly the same things I'm aware
and conscious of all the time.
The big question is how to get there ?
With kexec based dumping and the other options we already have, if the code
comes to a stage where it can be used effectively it for 2.6 stabilization
(at least in some of the trees), especially if it works for some of the
harder cases like dumping from a panic in an interrupt handler, and
analysing some of the tougher kernel problems that people run into, we will
begin to have a much better handle on what _really_ works well in practice
across various environments. Once we know that, its much easier to apply
the Japanese garden principle, or perhaps even start with an empty sandbox
and incrementally build patches starting from the bare minimal function.
So it could be a 2 step process:
1) Minimally invasive and hence easy to patch, but large piece of
code that can be configured to work reliably with wide applicability (so it
gets used sufficiently), and easily usable ASAP. Gives us a base to
discover what works and what is absolutely essential.
2) Incremental set of patches (with 2.7 in mind) that abstract the
essential pieces using a minimalist approach, and build up/follow on
patches for less important features.
There could be other ways too, of course. If (1) means a piece of code that
is difficult to maintain and prone to bugs itself, it may not get used
enough for us to have the answers ... in that case we would need a
different approach. What's your sense on this ?
Maybe we should keep your comments in the Todo file, to serve as a constant
reminder, and jot down some action points towards the goal.
Linux Technology Center
IBM Software Lab, India
6th floor, DLF Square, Gurgaon
E-mail : bsuparna@...
Phone : 91-124-6560303, Extn: 744
<shemminger@...> To: suparna@...
Sent by: cc: lkcd-devel@..., Tom
lkcd-devel-admin@... Hanrahan/Beaverton/IBM@..., bharata@...
ceforge.net Subject: Re: [lkcd-devel] Todo List for LKCD for 2.5
02/11/03 10:46 PM
On Tue, 2003-02-11 at 06:50, Suparna Bhattacharya wrote:
> Here's an attempt at putting down some of the todos
> that come to mind for a start. Please feel free to
> add items that are missing.
> I have tried to follow a rough ordering in terms of
> priority in each of the categories, though not in a
> very strict/hard and fast sense.
> What's the best place to maintain this ?
It seems LKCD has grown too big, with too many features.
The goal should be to figure out how to do:
* Get crash dump into the main line kernel in 2.7.
Feedback from Linus and initial submittal seems to be ignored or
* Safely, reliably, dump
- Always disable interrupts
- Use as little of the OS as possible
- Maybe only network or memory dump.
* Apply the Japanese Garden principle:
"It is not complete until everything that can be removed is"
* Why have so many options about compression etc. Find what works.
* Why have a separate lcrash program? Dump in core format and make each
CPU look like a thread.
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
lkcd-devel mailing list