On Thu, Mar 12, 2015 at 2:07 AM, Shawn Landden <sh...@churchofgit.com> wrote: > On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers <k...@vrfy.org> wrote: >> >> On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden <sh...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
