> >> maybe could have one switch in /proc so could not disable that for > >> some kexec path... > > > > I fail to comprehend the benefits of kexec, > > and the requirements that kexec puts on the kernel, other than: > > > > # CONFIG_KEXEC is not set > > > > for me: it is a tools that i could use to make sure root-cause is in FW, and BIOS guys will not kick back the ball to os team. > after modifying table or hw reg in first kernel, and kexec even stock kernel, everything will work well. For ACPI, we already have the ability to override the BIOS tables upon the 1st boot. I don't know which BIOS guys you refer to, but when we find a BIOS bug and have access to the associated BIOS developer, we've never needed to do such a demonstration to convince them they have a bug. kexec seems like a science project that has a chance of working only under extremely controlled conditions. I have no problem with that, as long as it is not built into my kernel. But say kexec is useful to somebody out there -- what are the requirements that kexec puts on the kernel? -Len -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
