Yes, we are putting that in as one of the alternative dump targets
available. I have done quite a bit of work on that implementing the
ideas we talked about at OLS, and that's what I've been referring
to as the memory dump target. Its not quite ready yet and we
need something like kexec to be available which we can use on Intel
systems to achieve the softboot (the acceptance status of that still
doesn't seem to be clear), so I was looking at this as a
follow-on thing once the core infrastructure is there. More so
because we probably need to give it some time to stabilize and try
it on different environments and look at the issues you mention.
Why do we even consider the other options when we are doing
this already ? Well, as we discussed earlier there's non-disruptive dumps
for one, where this wouldn't work. The other is that before overwriting
memory we need to be able to stop all activity in the system for certain
(system may appear hung/locked up) and I'm not fully certain about
how to do this for all environments. Maybe an answer lies in
rethinking some parts of the algorithm a bit.
Also having the interface allows people to develop more specific/
reliable solutions for their environment. So we do not necessiate
code duplication, but if something exists, then the infrastructure
can use it.
The general feeling here is that a one solution fits all thing
may not work best right now ... and hence the focus on an interface
based approach that gives us the needed flexibility.
> at the LKCD code, but the descriptions sound as if all the
> special-case cruft seems to be back again, which I would find a
> little disappointing.
Hope that helps a bit.
> There might be a case for specialized low-overhead dump handlers
> for small embedded systems and such, but they're probably better
> maintained outside of the mainstream kernel. (They're more like
> firmware anyway.)
> - Werner
> / Werner Almesberger, Buenos Aires, Argentina firstname.lastname@example.org /
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> lkcd-devel mailing list
-- Suparna Bhattacharya (email@example.com) Linux Technology Center IBM Software Labs, India
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/