Discussion:
Move loader.c out of the kernel
phcoder
2009-03-22 12:48:21 UTC
Permalink
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
2009-03-22 Vladimir Serbinenko <***@gmail.com>

Move loader out of the kernel

* kern/loader.c: moved to ...
* commands/boot.c: ... moved here
* commands/minicmd.c (grub_mini_cmd_boot): moved to ...
* commands/boot.c (grub_cmd_boot): moved here. All users updated
* include/grub/kernel.h (grub_machine_fini): export
* include/grub/loader.h (grub_loader_is_loaded): update declaration
(grub_loader_set): likewise
(grub_loader_unset): likewise
(grub_loader_boot): likewise
* conf/common.rmk: new module boot.mod
(pkglib_MODULES): add boot.mod
* conf/i386-coreboot.rmk (kernel_elf_SOURCES): remove kern/loader.c
(grub_emu_SOURCES): likewise
* conf/i386-efi.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/i386-ieee1275.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/i386-pc.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/powerpc-ieee1275.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/sparcs64-ieee1275.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/x86_64-efi.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
--
Regards
Vladimir 'phcoder' Serbinenko
Yoshinori K. Okuji
2009-03-22 12:57:33 UTC
Permalink
Post by phcoder
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
This is not useful in reality, because the loader interface needs to be
pre-loaded into core.img anyway. Note that the more you split code into
modules, the more the size of core.img is, as long as they are all
pre-loaded.

Regards,
Okuji
phcoder
2009-03-22 13:06:36 UTC
Permalink
Post by Yoshinori K. Okuji
Post by phcoder
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
This is not useful in reality, because the loader interface needs to be
pre-loaded into core.img anyway.
Why? I successfully tested core.img with just pc fat and biosdisk
modules integrated. It loads boot.mod just fine and boots linux and
multiboot with no problem
Post by Yoshinori K. Okuji
Note that the more you split code into
modules, the more the size of core.img is, as long as they are all
pre-loaded.
Regards,
Okuji
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
Yoshinori K. Okuji
2009-03-22 13:12:33 UTC
Permalink
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
This is not useful in reality, because the loader interface needs to be
pre-loaded into core.img anyway.
Why? I successfully tested core.img with just pc fat and biosdisk
modules integrated. It loads boot.mod just fine and boots linux and
multiboot with no problem
Try the rescue mode with no extra module loaded. If the core.img does not have
any loader, it is useless.

Okuji
Post by phcoder
Post by Yoshinori K. Okuji
Note that the more you split code into
modules, the more the size of core.img is, as long as they are all
pre-loaded.
Regards,
Okuji
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
phcoder
2009-03-22 13:30:24 UTC
Permalink
Post by Yoshinori K. Okuji
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
This is not useful in reality, because the loader interface needs to be
pre-loaded into core.img anyway.
Why? I successfully tested core.img with just pc fat and biosdisk
modules integrated. It loads boot.mod just fine and boots linux and
multiboot with no problem
Try the rescue mode with no extra module loaded. If the core.img does not have
any loader, it is useless.
If it's unable to read FS then it can't boot much anyway. If it's it can
load modules from its own partition. The only use I see is when grub
partition is corrupted but OS one is intact and you already have FS
driver for root in grub2.
Alternatively commands/boot.c can be a part of minicmd
Post by Yoshinori K. Okuji
Okuji
Post by phcoder
Post by Yoshinori K. Okuji
Note that the more you split code into
modules, the more the size of core.img is, as long as they are all
pre-loaded.
Regards,
Okuji
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
Yoshinori K. Okuji
2009-03-22 14:01:41 UTC
Permalink
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
This is not useful in reality, because the loader interface needs to be
pre-loaded into core.img anyway.
Why? I successfully tested core.img with just pc fat and biosdisk
modules integrated. It loads boot.mod just fine and boots linux and
multiboot with no problem
Try the rescue mode with no extra module loaded. If the core.img does not
have any loader, it is useless.
If it's unable to read FS then it can't boot much anyway. If it's it can
load modules from its own partition. The only use I see is when grub
partition is corrupted but OS one is intact and you already have FS
driver for root in grub2.
Alternatively commands/boot.c can be a part of minicmd
"cannot load any more module" != "cannot read the filesystem"

The most typical case is where the user has failed in installing GRUB
correctly; in this case, the user can still reset the prefix, and load
normal.mod manually. But, surprisingly, some users accidentally remove
modules. Indeed, I have heard many times this kind of "bug reports" in GRUB
Legacy. In this case, the only way is to boot an OS somehow and re-install
GRUB.

Regards,
Okuji
phcoder
2009-03-22 14:19:09 UTC
Permalink
Post by Yoshinori K. Okuji
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
This is not useful in reality, because the loader interface needs to be
pre-loaded into core.img anyway.
Why? I successfully tested core.img with just pc fat and biosdisk
modules integrated. It loads boot.mod just fine and boots linux and
multiboot with no problem
Try the rescue mode with no extra module loaded. If the core.img does not
have any loader, it is useless.
If it's unable to read FS then it can't boot much anyway. If it's it can
load modules from its own partition. The only use I see is when grub
partition is corrupted but OS one is intact and you already have FS
driver for root in grub2.
Alternatively commands/boot.c can be a part of minicmd
"cannot load any more module" != "cannot read the filesystem"
The most typical case is where the user has failed in installing GRUB
correctly; in this case, the user can still reset the prefix, and load
normal.mod manually. But, surprisingly, some users accidentally remove
modules. Indeed, I have heard many times this kind of "bug reports" in GRUB
Legacy. In this case, the only way is to boot an OS somehow and re-install
GRUB.
Well if user damages grub2 then we can't do much. He can also accidently
rewrite mbr or first track (some non-booting-realted software does it
on purpose). For failsafe solution only cd is a viable alternative
grub-install already handles the correct installation of grub2.
Additionally if user has "accidently" deleted modules chances are he
used grub-install or some wrapper around it. But grub-install doesn't
put any loader modules to core.img.
Post by Yoshinori K. Okuji
Regards,
Okuji
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
Yoshinori K. Okuji
2009-03-22 14:59:03 UTC
Permalink
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Post by Yoshinori K. Okuji
Post by phcoder
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
This is not useful in reality, because the loader interface needs to
be pre-loaded into core.img anyway.
Why? I successfully tested core.img with just pc fat and biosdisk
modules integrated. It loads boot.mod just fine and boots linux and
multiboot with no problem
Try the rescue mode with no extra module loaded. If the core.img does
not have any loader, it is useless.
If it's unable to read FS then it can't boot much anyway. If it's it can
load modules from its own partition. The only use I see is when grub
partition is corrupted but OS one is intact and you already have FS
driver for root in grub2.
Alternatively commands/boot.c can be a part of minicmd
"cannot load any more module" != "cannot read the filesystem"
The most typical case is where the user has failed in installing GRUB
correctly; in this case, the user can still reset the prefix, and load
normal.mod manually. But, surprisingly, some users accidentally remove
modules. Indeed, I have heard many times this kind of "bug reports" in
GRUB Legacy. In this case, the only way is to boot an OS somehow and
re-install GRUB.
Well if user damages grub2 then we can't do much. He can also accidently
rewrite mbr or first track (some non-booting-realted software does it
on purpose).
I know that this is very rare by experience, in comparison with just having
removed/broke many things from/in a filesystem.
Post by phcoder
For failsafe solution only cd is a viable alternative
If you have experience on maintaining remote hardware, you should know that
this is not viable.
Post by phcoder
grub-install already handles the correct installation of grub2.
Additionally if user has "accidently" deleted modules chances are he
used grub-install or some wrapper around it. But grub-install doesn't
put any loader modules to core.img.
grub-install itself does whatever the user specifies. If your core.img does
not include necessary modules pre-loaded, that's your mistake or your
distributor's.

Regards,
Okuji
Robert Millan
2009-03-22 14:54:51 UTC
Permalink
Post by Yoshinori K. Okuji
Post by phcoder
If it's unable to read FS then it can't boot much anyway. If it's it can
load modules from its own partition. The only use I see is when grub
partition is corrupted but OS one is intact and you already have FS
driver for root in grub2.
Alternatively commands/boot.c can be a part of minicmd
"cannot load any more module" != "cannot read the filesystem"
The most typical case is where the user has failed in installing GRUB
correctly;
In my experience dealing with grub2 bug reports in debian, the most common
case where user entered rescue mode is some bug in grub.

As grub becomes more mature, this may become less of an issue, but then again
an automated install process is provided by the distribution. If users want
to tinker and install things by hand, and they make mistakes, I think they
should learn to either do things right or let the distribution scripts do it
for them.

Or to put it another way, "nothing is fool-proof to a sufficiently talented
fool" :-)
--
Robert Millan

The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
phcoder
2009-03-31 08:56:24 UTC
Permalink
With a new swing in normal.mod splitting I think we should reconsider
this patch. It's useless to keep loader.c in kernel without boot
command. IMO it should be moved either to a perate boot.mod (my
preference) or to minicmd.mod (not a good option IMO)
Post by phcoder
Hello. Now when boot command isn't in kernel anymore I don't see why
loader.c stays in kernel. Here is the patch to move it to boot.mod
Move loader out of the kernel
* kern/loader.c: moved to ...
* commands/boot.c: ... moved here
* commands/minicmd.c (grub_mini_cmd_boot): moved to ...
* commands/boot.c (grub_cmd_boot): moved here. All users updated
* include/grub/kernel.h (grub_machine_fini): export
* include/grub/loader.h (grub_loader_is_loaded): update declaration
(grub_loader_set): likewise
(grub_loader_unset): likewise
(grub_loader_boot): likewise
* conf/common.rmk: new module boot.mod
(pkglib_MODULES): add boot.mod
* conf/i386-coreboot.rmk (kernel_elf_SOURCES): remove kern/loader.c
(grub_emu_SOURCES): likewise
* conf/i386-efi.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/i386-ieee1275.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/i386-pc.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/powerpc-ieee1275.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/sparcs64-ieee1275.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
* conf/x86_64-efi.rmk (kernel_elf_SOURCES): likewise
(grub_emu_SOURCES): likewise
--
Regards
Vladimir 'phcoder' Serbinenko
Yoshinori K. Okuji
2009-04-01 13:52:26 UTC
Permalink
Post by phcoder
With a new swing in normal.mod splitting I think we should reconsider
this patch. It's useless to keep loader.c in kernel without boot
command. IMO it should be moved either to a perate boot.mod (my
preference) or to minicmd.mod (not a good option IMO)
As I said, rescue mode is not quite useful without any loader. So the loader
interface should be built into the kernel, and the boot command should be as
well naturally.

Regards,
Okuji
Robert Millan
2009-04-01 14:19:32 UTC
Permalink
Post by Yoshinori K. Okuji
Post by phcoder
With a new swing in normal.mod splitting I think we should reconsider
this patch. It's useless to keep loader.c in kernel without boot
command. IMO it should be moved either to a perate boot.mod (my
preference) or to minicmd.mod (not a good option IMO)
As I said, rescue mode is not quite useful without any loader. So the loader
interface should be built into the kernel, and the boot command should be as
well naturally.
This presses for more space into core.img, which is highly constrained
(specially in weird combinations like raid + lvm or crypto in the future).

Why is a loader so important for rescue mode? If the loader would work, it
means you can read files, so it should be able to load the rest of modules
as well.

When user is dumped to rescue mode, usually (at least for reports I dealt with
in debian) it means GRUB has a bug or didn't setup itself properly, and the
/boot/ directory can't be accessed. A loader wouldn't help in these
situations.

Also, how do you determine which loaders belong in kernel? There can be
many specialized loaders like the linux one. Or we could just put multiboot,
but the Multiboot loader is quite complex already, and it still has room
for growing. Maybe the answer is to write a very simple Multiboot loader
and put that in kernel?
--
Robert Millan

The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Yoshinori K. Okuji
2009-04-01 14:42:22 UTC
Permalink
Post by Robert Millan
Post by Yoshinori K. Okuji
Post by phcoder
With a new swing in normal.mod splitting I think we should reconsider
this patch. It's useless to keep loader.c in kernel without boot
command. IMO it should be moved either to a perate boot.mod (my
preference) or to minicmd.mod (not a good option IMO)
As I said, rescue mode is not quite useful without any loader. So the
loader interface should be built into the kernel, and the boot command
should be as well naturally.
This presses for more space into core.img, which is highly constrained
(specially in weird combinations like raid + lvm or crypto in the future).
Why is a loader so important for rescue mode? If the loader would work, it
means you can read files, so it should be able to load the rest of modules
as well.
If some or all modules are trashed, no. Also, the user might be able to read
other partitions.
Post by Robert Millan
When user is dumped to rescue mode, usually (at least for reports I dealt
with in debian) it means GRUB has a bug or didn't setup itself properly,
and the /boot/ directory can't be accessed. A loader wouldn't help in
these situations.
And, the rescue mode does not help very much in this case.
Post by Robert Millan
Also, how do you determine which loaders belong in kernel? There can be
many specialized loaders like the linux one. Or we could just put
multiboot, but the Multiboot loader is quite complex already, and it still
has room for growing. Maybe the answer is to write a very simple Multiboot
loader and put that in kernel?
That's up to the user IMO. For example, suppose this kind of scenario:

- the user has a dual boot environment, say, GNU/Linux and Windows.
- she uses GRUB installed with the GNU/Linux.
- she has made something stupid in the GNU/Linux (e.g. rm -rf /).

In the case of GRUB Legacy, this is the end. It's just unbootable, because
stage 1.5 may not boot anything besides stage2.

In the case of GRUB 2, if the user has pre-loaded chainload.mod onto the
core.img, she can still boot the Windows.

Honestly, I am more interested in making it possible to use GRUB for setting
up a very robust environment. For example:

- the user installs a main OS and a rescue OS into a single machine. The
latter can be very compact (e.g. puppy, grml, etc.).
- she installs another boot loader into the partition for the rescue OS.
- she pre-loads chainload.mod in core.img.

I think the chainloader is the most realistic, because it is the smallest
loader, and GRUB does not need to read a filesystem, thus no filesystem
driver is required for loading an OS.

Every time I maintain a remote system, I feel the necessity of being prepared
for disasters (e.g. filesystem crashes). Rescue mode is one of the tools
required for this goal.

Regards,
Okuji
phcoder
2009-04-01 15:12:06 UTC
Permalink
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
Post by Yoshinori K. Okuji
Post by Robert Millan
Post by Yoshinori K. Okuji
Post by phcoder
With a new swing in normal.mod splitting I think we should reconsider
this patch. It's useless to keep loader.c in kernel without boot
command. IMO it should be moved either to a perate boot.mod (my
preference) or to minicmd.mod (not a good option IMO)
As I said, rescue mode is not quite useful without any loader. So the
loader interface should be built into the kernel, and the boot command
should be as well naturally.
This presses for more space into core.img, which is highly constrained
(specially in weird combinations like raid + lvm or crypto in the future).
Why is a loader so important for rescue mode? If the loader would work, it
means you can read files, so it should be able to load the rest of modules
as well.
If some or all modules are trashed, no. Also, the user might be able to read
other partitions.
Post by Robert Millan
When user is dumped to rescue mode, usually (at least for reports I dealt
with in debian) it means GRUB has a bug or didn't setup itself properly,
and the /boot/ directory can't be accessed. A loader wouldn't help in
these situations.
And, the rescue mode does not help very much in this case.
Post by Robert Millan
Also, how do you determine which loaders belong in kernel? There can be
many specialized loaders like the linux one. Or we could just put
multiboot, but the Multiboot loader is quite complex already, and it still
has room for growing. Maybe the answer is to write a very simple Multiboot
loader and put that in kernel?
- the user has a dual boot environment, say, GNU/Linux and Windows.
- she uses GRUB installed with the GNU/Linux.
- she has made something stupid in the GNU/Linux (e.g. rm -rf /).
In the case of GRUB Legacy, this is the end. It's just unbootable, because
stage 1.5 may not boot anything besides stage2.
In the case of GRUB 2, if the user has pre-loaded chainload.mod onto the
core.img, she can still boot the Windows.
Honestly, I am more interested in making it possible to use GRUB for setting
- the user installs a main OS and a rescue OS into a single machine. The
latter can be very compact (e.g. puppy, grml, etc.).
- she installs another boot loader into the partition for the rescue OS.
- she pre-loads chainload.mod in core.img.
I think the chainloader is the most realistic, because it is the smallest
loader, and GRUB does not need to read a filesystem, thus no filesystem
driver is required for loading an OS.
Every time I maintain a remote system, I feel the necessity of being prepared
for disasters (e.g. filesystem crashes). Rescue mode is one of the tools
required for this goal.
Regards,
Okuji
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen
2009-04-01 15:21:54 UTC
Permalink
Post by phcoder
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:
phcoder
2009-04-01 15:46:20 UTC
Permalink
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
Post by Vesa Jääskeläinen
Post by phcoder
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.
...
preboot_handler_address: dd 0
...
cmp [preboot_handler_address], 0
je no_preboot_handler
call [preboot_handler_address]
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
phcoder
2009-04-05 15:19:19 UTC
Permalink
On the IRC Yoshinori K. Okuji agreed that this move can be useful in
cases like lvm+raid and luks. Any further oppositions?
Post by phcoder
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
Post by Vesa Jääskeläinen
Post by phcoder
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.
...
preboot_handler_address: dd 0
...
cmp [preboot_handler_address], 0
je no_preboot_handler
call [preboot_handler_address]
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
phcoder
2009-04-15 12:46:03 UTC
Permalink
Commited
Post by phcoder
On the IRC Yoshinori K. Okuji agreed that this move can be useful in
cases like lvm+raid and luks. Any further oppositions?
Post by phcoder
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
Post by Vesa Jääskeläinen
Post by phcoder
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.
...
preboot_handler_address: dd 0
...
cmp [preboot_handler_address], 0
je no_preboot_handler
call [preboot_handler_address]
_______________________________________________
Grub-devel mailing list
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
Continue reading on narkive:
Loading...