Messages in this thread | | | Subject | Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps. | From | (Eric W. Biederman) | Date | 02 Feb 2005 07:45:11 -0700 |
| |
And the feedback begins :)
Itsuro Oda <oda@valinux.co.jp> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |