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

[Kay Sievers]

On Thu, Mar 12, 2015 at 2:36 AM, Shawn Landden <shawn at churchofgit.com> wrote:
> On Wed, Mar 11, 2015 at 6:24 PM, Kay Sievers <kay at vrfy.org> wrote:
>>
>> 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.
>>
> I thought you wrote a specification?
> freedesktop.org/wiki/Specifications/BootLoaderSpec/

It does not specify how to find or select new kernels, and it probably
never will. Boot loaders are free to add anything they want to offer.
The boot loader spec mainly tries to unify the explicit *configuration*,
but not the logic inside the boot loaders.

Even gummiboot has its own config file, which specifies the pattern for
the default selection logic, that is all intentionally not part of the spec,
but it changes the way the selection logic works inside the loader.

Now with the boot loader merged into system tree, we could potentially
share some code here, but I still don't see how all that fits together, and
we should find that out before we make any promises like that.

Kay