On Thu, Jan 8, 2009 at 10:55 PM, Len Brown <lenb@xxxxxxxxxx> wrote: >> >> 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. Your BIOS developer must have enough time or have bunch of BIOS engineers. > > 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. could reduce boot time. or some system has problem with reset... or linuxbios + tinykernel to kexec final production kernel. here linuxbios only init ram and basic pci resource allocation ... > > But say kexec is useful to somebody out there -- what are > the requirements that kexec puts on the kernel? the support got into the mainline kernel several years ago... from 2.6.16? YH -- 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
