And the feedback begins :) Itsuro Oda <[EMAIL PROTECTED]> writes:
> Hi, > > I don't like calling crash_kexec() directly in (ex.) panic(). > It should be call_dump_hook() (or something like this). > > I think the necessary modifications of the kernel is only: > - insert the hooks that calls a dump function when crash occur crash_kexec() > - binding interface that binds a dump function to the hook > (like register_dump_hook()) sys_kexec_load(...); > - supply the information of valid physical address regions /proc/iomem or possibly /proc/cpumem. At least until someone actually implements hot plug memory support. > (- maybe some existent functions and variables need to be exported ?) > > I think this makes any sort of dump functions can be implemented > as a kernel module. I don't think it is best way that the "kexec based > crashdump" is built in the kernel. For people developing code outside of the kernel I can see where this is a problem. Given the insane auditing requirements necessary to get a reliable code path I don't see how not putting the implementation in the kernel is sane. Anything that needs to be touched at that point is core kernel functionality GPL_ONLY if it is exported at all. Touching anything from a module at that point is not sane. Basically the code path setup with crash_kexec is little more than a jump instruction. And it should be audited and reduced as much as possible. I don't see how you get simpler or what piece of functionality could possibly improve by having multiple implementations in kernel modules. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
