Commited
phcoder wrote:
On the IRC Yoshinori K. Okuji agreed that this move can be useful in
cases like lvm+raid and luks. Any further oppositions?
phcoder wrote:
I was thinking about something more finished like the possibility of
handling multiple preboot and to undo the operations in case of failed
or returned boot. Potentially it could be moved to a separate module
but it results in a reverse dependency and somewhat ugly code
Vesa Jääskeläinen wrote:
phcoder wrote:
This usage case isn't the main target case. If you embed the loader
(which tend to be quite big) then you already have an overhead from
loader module. Why are you so concerned with overhead of boot.mod?
But on the other hand this forces all the people in other cases to have
boot code in core.img. I want to add preboot hooks and don't want
increment size of kernel. multiboot.mod currently increases the size by
around 11KB. And my patch doesn't restrict you from putting loader in
core.img in any way
Even if you add the preboot hooks there, it should only cause size
affect in couple of bytes for uncompressed image.
Like in following "sketch":
...
preboot_handler_address: dd 0
...
cmp [preboot_handler_address], 0
je no_preboot_handler
call [preboot_handler_address]
no_preboot_handler:
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
