> I'm not so convinced about this. I like the Mission Critical
> approach:
and so do many people. In fact netdump, mcode and lkcd are all
complementary parts of the same need. That's why we are working with
mcrit's blessing to merge mcore into lkcd. That's a big piece of work,
which we hope to make progress with during 2003 - Suparna's the expert :-)
Richard
Richard J Moore wrote:
> and so do many people. In fact netdump, mcode and lkcd are all
> complementary parts of the same need.
It's the "complementary" that worries me. Once you have mcore, what
good are direct dumps to the network or the disk for ? With mcore,
the whole issue of accessing stable storage is eliminated.
I don't know if the approach of having multiple quasi-equivalent
means of storing a dump is something that Linus dislikes about
LKCD, but I think it might be worth exploring if LKCD's chance of
acceptance could be improved by focusing on a single but general
mechanism.
I think it would be a pity if we ended up not having crash dumps
in 2.6 only because they're over-featured ...
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
On Thu, Oct 31, 2002 at 08:39:35PM -0300, Werner Almesberger wrote:
> Richard J Moore wrote:
> > and so do many people. In fact netdump, mcode and lkcd are all
> > complementary parts of the same need.
>
> It's the "complementary" that worries me. Once you have mcore, what
> good are direct dumps to the network or the disk for ? With mcore,
> the whole issue of accessing stable storage is eliminated.
>
> I don't know if the approach of having multiple quasi-equivalent
> means of storing a dump is something that Linus dislikes about
> LKCD, but I think it might be worth exploring if LKCD's chance of
> acceptance could be improved by focusing on a single but general
> mechanism.
The very question that's kept me up late some nights :)
And one of the reasons for spending so much time in integrating
mcore seamlessly into the lkcd framework rather than plug it in
as is at a high level. Precisely to avoid bloat while retaining
flexibility and to move from something that works today to
more improved schemes in the future.
The decision on what dump device implementations - block, net,
memory, and other special types to include could be a separate
one from the base dump system, and could change as time passes.
>
> I think it would be a pity if we ended up not having crash dumps
> in 2.6 only because they're over-featured ...
The dump driver interface is pretty simple, if you look at it
.. though it was meant to be powerful enough to do a lot of nice
things in the future.
Regards
Suparna
>
> - Werner
>
> --
> _________________________________________________________________________
> / Werner Almesberger, Buenos Aires, Argentina [email protected] /
> /_http://www.almesberger.net/____________________________________________/
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> lkcd-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lkcd-devel
--
Suparna Bhattacharya ([email protected])
Linux Technology Center
IBM Software Labs, India