> 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. Reasonable engineers do not need their own bugs handed to them on a silver platter. > > 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. Effort would be better spent on reducing boot time w/ kexec. > 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 ... My understanding is that the linuxbios people realized that creating a BIOS that boots Linux (tiny or not) only to then boot Linux again, was sort of subgenius. So they re-named linuxbios to be coreboot and now they talk about loading a "payload".... > > 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? I'm afraid I'm not being clear. This conversation started when you suggested that we should put a hook in to ask ACPI to manipulate Link state for the benefit of kexec. My question is, what else does kexec need to properly manage the state of the sytem? I don't think that question has an answer. I don't think it will ever have an answer. I think that kexec is a viable concept only under conditions I don't care about. -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
