Re: why kexec (was Re: [PATCH 2/2] ACPI: PCI Interrupt Links -- disable when unused)

Yinghai Lu
2009-01-09T07:24:16Z

On Thu, Jan 8, 2009 at 10:55 PM, Len Brown <lenb@kernel.org> 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