[systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily

Kay Sievers kay at vrfy.org
Wed Mar 11 18:24:31 PDT 2015


On Thu, Mar 12, 2015 at 2:07 AM, Shawn Landden <shawn at churchofgit.com> wrote:
> On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers <kay at vrfy.org> wrote:
>>
>> On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden <shawn at churchofgit.com>
>> wrote:
>> > Still use helper when Xen Dom0, to avoid duplicating some hairy code.
>> >
>> > I think the rbtree version was far more understandable as
>> > greedy_realloc0()
>> > is very messy to do correctly.
>> >
>> > Take fopenat() from lsof.
>> > Add opendirat()
>>
>> We have that in util.c :: xopendirat()
>>
>> > Future: generate BootLoaderSpec files for other kernel install locations
>>
>> This approach duplicates, the potentially complex, boot manager kernel
>> selection logic.
>>
>> The recent systemd-boot boot loader and efi stub loader which carries
>> the kernel, the cmdline, the initrd in one single EFI binary will also
>> not use any boot loader snippets, it will be discovered by the loader
>> itself, which parses the PE/COFF files and looks for specific content.
>>
>> The snippets are meant to unify the boot loader *configuration*, but
>> they do not mean that every bootable kernel will or should have one.
>> There might be many ways for kernels to be found by the boot loader,
>> the snippets are just one source for that.
>>
>> I'm not sure what exact problem this patch tries to solve,
>
> rebooting with kexec is faster than a full reboot. Currently we do not
> support kexec very well. Lennart asked for something like this, but perhaps
> we no longer want to support kexec loading?

I kind of miss a description what this change is supposed to support
in the end. It can't be described with "replacing a call to a binary".

Automatic searching and deciding what kernel to boot, and how to
search for these kernels, and how all that should continue to work
reliably in the longer run, while the boot loaders underneath improve
and change; that is something we should define before and have a clear
idea, before we copy only parts of that logic from the current tools.

Thanks,
Kay


More information about the systemd-devel mailing list