multiboot2

multiboot2

[phcoder]

Hello I was looking into multiboot2 specifications and have some 
suggestions:
1) double the size of flags. 8 features per category seems to be few. it 
could even be made completely expandable by the following format:
<magic>
<number of flag dwords>
<dword1 as defined in current draft>
<dword2 as defined in current draft, next packet of flags>
...
<checksum>
2) "All undefined flags *should* be set to zero for future use. "
IMO in this place all OSes should be required to follow this rule in 
current terminology it would be "must"
3) "The physical address to which the boot loader should jump in order 
to start running the operating system."
In current terminology should make no real sense here
4) "This tag should contain a string that enables operating systems to 
distinguish between different bootloaders and different versions of the 
same bootloader."
Parsing strings may be difficult. Perhaps we could include a version tag 
with a format dependent on bootloader and optionally a requirement that 
higher numbers are newer versions?
5)memory map: "The order of memory maps is not guaranteed but a boot 
loader should sort the items based on the starting addresses. "
I don't like the optionality of this rule if it's included in 
specifications it should be either required or dropped altogether. 
Otherwise we risk to have OSes which rely on sorting and bootloaders 
which doesn't sort. I'm personally for making it mandatory for reasons 
similar to next entry
6) memory map. "<!> Tags of this type should be omitted on architectures 
where the OS is able to retrieve this information from firmware. (Doing 
do will encourage OS portability across bootloaders, and simplify GRUB 
development and maintenance.) "
This contradicts the goal of easier OS developement and may result in 
semi-compatible OS and bootloaders. Additionally I think that 
eliminating the necessity of use of firmware from OS is a good thing and 
allows easier porting between architectures differing only by firmware
7) Command line tag. I propose to reserve the identifier 0x0005 for 
command line and make it the same format as "Boot Loader Name" but 
arguments shouldn't include kernel image name. This way we would prevent 
OSes from trying to access this file by bootloader-specific name. In 
addition in both "Boot Loader Name" and "Command-line" we should specify 
the encoding to be utf-8


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: multiboot2

[Kevin Lacquement]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

phcoder wrote:

[...]

> 4) "This tag should contain a string that enables operating systems to
> distinguish between different bootloaders and different versions of the
> same bootloader."
> Parsing strings may be difficult. Perhaps we could include a version tag
> with a format dependent on bootloader and optionally a requirement that
> higher numbers are newer versions?

By my understanding, the name is defined by the bootloader.  All Grub
has to do is check if it starts with "GRUB" (or whatever
name/capitalization we define), and skip otherwise.  If, for example, it
starts with "LILO", we can skip the entire tag and not worry about
parsing LILO's version numbers.

With that, you also don't need to worry about "higher numbers are newer
version", as we can determine our own versioning, and load appropriate
features.


> 7) Command line tag. I propose to reserve the identifier 0x0005 for
> command line and make it the same format as "Boot Loader Name" but
> arguments shouldn't include kernel image name. This way we would prevent
> OSes from trying to access this file by bootloader-specific name. In
> addition in both "Boot Loader Name" and "Command-line" we should specify
> the encoding to be utf-8

I'm not really understanding what you're saying here.  Are you proposing
that the OS lets us know what command-line options it allows, for use in
tab completion?  Or that they're listing the default command line (for
editing perhaps?)  Or am I thinking in the wrong direction here?

-- 
Sic non confunctus, non reficiat.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: multiboot2

[phcoder]

In 4 and 7 I meant parameters passed from the bootloader to the OS.
> With that, you also don't need to worry about "higher numbers are newer
> version", as we can determine our own versioning, and load appropriate
> features.
With that we can avoid alternative bootloaders with version passing like 
13b5.1.1rc2
Which would be an unnecessary hassle for the OS to parse.
> 
> I'm not really understanding what you're saying here.  Are you proposing
> that the OS lets us know what command-line options it allows, for use in
> tab completion?  Or that they're listing the default command line (for
> editing perhaps?)  Or am I thinking in the wrong direction here?
Yes you're. I mean command line parameters. E.g. if you launch the 
kernel like
multiboot /mykernel root=myroot debug=ttyS0
Then kernel should be able to know what's passed after the kernel name I 
propose it to be exported as a tag 0x0005 and contents
"root=myroot debug=ttyS0" as a NUL-terminated UTF-8 string
-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: multiboot2

[phcoder]

These issues still remain
phcoder wrote:
> Hello I was looking into multiboot2 specifications and have some 
> suggestions:
> 1) double the size of flags. 8 features per category seems to be few. it 
> could even be made completely expandable by the following format:
> <magic>
> <number of flag dwords>
> <dword1 as defined in current draft>
> <dword2 as defined in current draft, next packet of flags>
> ...
> <checksum>
> 2) "All undefined flags *should* be set to zero for future use. "
> IMO in this place all OSes should be required to follow this rule in 
> current terminology it would be "must"
> 3) "The physical address to which the boot loader should jump in order 
> to start running the operating system."
> In current terminology should make no real sense here
> 4) "This tag should contain a string that enables operating systems to 
> distinguish between different bootloaders and different versions of the 
> same bootloader."
> Parsing strings may be difficult. Perhaps we could include a version tag 
> with a format dependent on bootloader and optionally a requirement that 
> higher numbers are newer versions?
> 5)memory map: "The order of memory maps is not guaranteed but a boot 
> loader should sort the items based on the starting addresses. "
> I don't like the optionality of this rule if it's included in 
> specifications it should be either required or dropped altogether. 
> Otherwise we risk to have OSes which rely on sorting and bootloaders 
> which doesn't sort. I'm personally for making it mandatory for reasons 
> similar to next entry
> 6) memory map. "<!> Tags of this type should be omitted on architectures 
> where the OS is able to retrieve this information from firmware. (Doing 
> do will encourage OS portability across bootloaders, and simplify GRUB 
> development and maintenance.) "
> This contradicts the goal of easier OS developement and may result in 
> semi-compatible OS and bootloaders. Additionally I think that 
> eliminating the necessity of use of firmware from OS is a good thing and 
> allows easier porting between architectures differing only by firmware
> 7) Command line tag. I propose to reserve the identifier 0x0005 for 
> command line and make it the same format as "Boot Loader Name" but 
> arguments shouldn't include kernel image name. This way we would prevent 
> OSes from trying to access this file by bootloader-specific name. In 
> addition in both "Boot Loader Name" and "Command-line" we should specify 
> the encoding to be utf-8
> 
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: multiboot2

[Yoshinori K. Okuji]

On Monday 06 April 2009 08:34:23 phcoder wrote:
> These issues still remain
>
> phcoder wrote:
> > Hello I was looking into multiboot2 specifications and have some
> > suggestions:
> > 1) double the size of flags. 8 features per category seems to be few.

I do not agree on this. As you can see, most bits are still undefined after 
over 10-year usage of the Multiboot Specification. I do not want to change it 
without any real issue.

> > it 
> > could even be made completely expandable by the following format:
> > <magic>
> > <number of flag dwords>
> > <dword1 as defined in current draft>
> > <dword2 as defined in current draft, next packet of flags>
> > ...
> > <checksum>

This (i.e. a variable Multiboot header) has been raised several times on this 
list, and my conclusion is that it is not desirable.

> > 2) "All undefined flags *should* be set to zero for future use. "
> > IMO in this place all OSes should be required to follow this rule in
> > current terminology it would be "must"

I agree.

> > 3) "The physical address to which the boot loader should jump in order
> > to start running the operating system."
> > In current terminology should make no real sense here

This is not an italic "should". Just a natural use of English wording.

> > 4) "This tag should contain a string that enables operating systems to
> > distinguish between different bootloaders and different versions of the
> > same bootloader."
> > Parsing strings may be difficult. Perhaps we could include a version tag
> > with a format dependent on bootloader and optionally a requirement that
> > higher numbers are newer versions?

I do not think so. The purpose of this tag is for human reading only. For 
example, you might want to examine what boot loader booted up your operating 
system. So, as long as it is readable for human, that's okay. IMO, operating 
systems must not change behaviors based on this tag.

> > 5)memory map: "The order of memory maps is not guaranteed but a boot
> > loader should sort the items based on the starting addresses. "
> > I don't like the optionality of this rule if it's included in
> > specifications it should be either required or dropped altogether.
> > Otherwise we risk to have OSes which rely on sorting and bootloaders
> > which doesn't sort. I'm personally for making it mandatory for reasons
> > similar to next entry

There's a good reason to make it optional. If you see GRUB only, you will 
think that this behavior should be always implemented, but some boot loaders 
are more nervous about the code size, so they want to skip as many features 
as they can. In fact, AFAIK, Etherboot didn't implement sorting in its 
Multiboot support.

> > 6) memory map. "<!> Tags of this type should be omitted on architectures
> > where the OS is able to retrieve this information from firmware. (Doing
> > do will encourage OS portability across bootloaders, and simplify GRUB
> > development and maintenance.) "
> > This contradicts the goal of easier OS developement and may result in
> > semi-compatible OS and bootloaders. Additionally I think that
> > eliminating the necessity of use of firmware from OS is a good thing and
> > allows easier porting between architectures differing only by firmware

It is hard for me to say which is better.

In reality, every OS needs to interact with underlying firmware more or less 
to be functional (power control, interrupt handling, etc.). So giving a 
memory map does not eliminate the necessity of interactions with firmware 
anyway.

From another viewpoint, a boot loader can declare a part of memory for its own 
use, even after transferring control to an operating system, by specifying a 
memory map explicitly. So it can be useful to provide a memory map, even on 
an architecture which offers support for retrieving a memory map easily.

> > 7) Command line tag. I propose to reserve the identifier 0x0005 for
> > command line and make it the same format as "Boot Loader Name" but
> > arguments shouldn't include kernel image name. This way we would prevent
> > OSes from trying to access this file by bootloader-specific name. In
> > addition in both "Boot Loader Name" and "Command-line" we should specify
> > the encoding to be utf-8

Seemingly, someone made a bad change on the draft, so the information is lost:

http://grub.enbug.org/MultibootDraft?action=diff&rev2=23&rev1=22

Hollis's idea was to use the same format as for modules to give information 
about an OS image. A part of this change must be reverted. It is wrong to 
adopt the spec to the implementation.

BTW, I agree that the command line should not include a filename.

Regards,
Okuji

Re: multiboot2

[phcoder]

Yoshinori K. Okuji wrote:
>>> 1) double the size of flags. 8 features per category seems to be few.
> 
> I do not agree on this. As you can see, most bits are still undefined after 
> over 10-year usage of the Multiboot Specification. I do not want to change it 
> without any real issue.
> 
The difference is that multiboot2 is meant to be portable
>>> 3) "The physical address to which the boot loader should jump in order
>>> to start running the operating system."
>>> In current terminology should make no real sense here
> 
> This is not an italic "should". Just a natural use of English wording.
Ok
> 
>>> 4) "This tag should contain a string that enables operating systems to
>>> distinguish between different bootloaders and different versions of the
>>> same bootloader."
>>> Parsing strings may be difficult. Perhaps we could include a version tag
>>> with a format dependent on bootloader and optionally a requirement that
>>> higher numbers are newer versions?
> 
> I do not think so. The purpose of this tag is for human reading only. For 
> example, you might want to examine what boot loader booted up your operating 
> system. So, as long as it is readable for human, that's okay. IMO, operating 
> systems must not change behaviors based on this tag.
> 
Ok
>>> 5)memory map: "The order of memory maps is not guaranteed but a boot
>>> loader should sort the items based on the starting addresses. "
>>> I don't like the optionality of this rule if it's included in
>>> specifications it should be either required or dropped altogether.
>>> Otherwise we risk to have OSes which rely on sorting and bootloaders
>>> which doesn't sort. I'm personally for making it mandatory for reasons
>>> similar to next entry
> 
> There's a good reason to make it optional. If you see GRUB only, you will 
> think that this behavior should be always implemented, but some boot loaders 
> are more nervous about the code size, so they want to skip as many features 
> as they can. In fact, AFAIK, Etherboot didn't implement sorting in its 
> Multiboot support.
> 
What I want is to avoid is the bitrot as with multiboot1 when due to 
different issues some kernels boot only with some booters. Such a 
situation defeats the purpose of the standard
>>> 6) memory map. "<!> Tags of this type should be omitted on architectures
>>> where the OS is able to retrieve this information from firmware. (Doing
>>> do will encourage OS portability across bootloaders, and simplify GRUB
>>> development and maintenance.) "
>>> This contradicts the goal of easier OS developement and may result in
>>> semi-compatible OS and bootloaders. Additionally I think that
>>> eliminating the necessity of use of firmware from OS is a good thing and
>>> allows easier porting between architectures differing only by firmware
> 
> It is hard for me to say which is better.
> 
> In reality, every OS needs to interact with underlying firmware more or less 
> to be functional (power control, interrupt handling, etc.). So giving a 
> memory map does not eliminate the necessity of interactions with firmware 
> anyway.
> 
This isn't entirely true. Most of OS use their own firmware-independent 
drivers for most devices. If it doesn't recognize the firmware perhaps 
some functionality will be disabled but at least OS will be able to boot.
This isn't the case with a lot of current OSes specifically targetting 
one or another firmware but I hope it will vhange in the future because 
of advent of alternative firmwares.
Furthermore different firmwares may implement the same interfaces. A 
major example is EFI, coreboot and BIOS implementing ACPI. If we add a 
tag pointing to RSDP then the kernel won't need to know whether it's on 
EFI, BIOS or coreboot.
>>> 7) Command line tag. I propose to reserve the identifier 0x0005 for
>>> command line and make it the same format as "Boot Loader Name" but
>>> arguments shouldn't include kernel image name. This way we would prevent
>>> OSes from trying to access this file by bootloader-specific name. In
>>> addition in both "Boot Loader Name" and "Command-line" we should specify
>>> the encoding to be utf-8
> 
> Seemingly, someone made a bad change on the draft, so the information is lost:
> 
> http://grub.enbug.org/MultibootDraft?action=diff&rev2=23&rev1=22
> 
> Hollis's idea was to use the same format as for modules to give information 
> about an OS image. A part of this change must be reverted. It is wrong to 
> adopt the spec to the implementation.
> 
It's ok with me. Quick look through the code suggests that probably 
kernel tag is created with type MODULE and that it also has an 
additional field type. I will check it tomorrow but it looks like a bug 
somewhere
And what about encoding?
> BTW, I agree that the command line should not include a filename.

> 
> Regards,
> Okuji
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: multiboot2

[Yoshinori K. Okuji]

On Tuesday 07 April 2009 10:18:30 phcoder wrote:
> Yoshinori K. Okuji wrote:
> >>> 1) double the size of flags. 8 features per category seems to be few.
> >
> > I do not agree on this. As you can see, most bits are still undefined
> > after over 10-year usage of the Multiboot Specification. I do not want to
> > change it without any real issue.
>
> The difference is that multiboot2 is meant to be portable

Yes, but so?

> > There's a good reason to make it optional. If you see GRUB only, you will
> > think that this behavior should be always implemented, but some boot
> > loaders are more nervous about the code size, so they want to skip as
> > many features as they can. In fact, AFAIK, Etherboot didn't implement
> > sorting in its Multiboot support.
>
> What I want is to avoid is the bitrot as with multiboot1 when due to
> different issues some kernels boot only with some booters. Such a
> situation defeats the purpose of the standard

Not really. Even with the most strict spec possible, it is always possible to 
depend on implementation details which are not part of the spec. So, if an OS 
image does boot only with some implementations, it is a fault in the OS 
image, and the OS image should be fixed.

> >>> 6) memory map. "<!> Tags of this type should be omitted on
> >>> architectures where the OS is able to retrieve this information from
> >>> firmware. (Doing do will encourage OS portability across bootloaders,
> >>> and simplify GRUB development and maintenance.) "
> >>> This contradicts the goal of easier OS developement and may result in
> >>> semi-compatible OS and bootloaders. Additionally I think that
> >>> eliminating the necessity of use of firmware from OS is a good thing
> >>> and allows easier porting between architectures differing only by
> >>> firmware
> >
> > It is hard for me to say which is better.
> >
> > In reality, every OS needs to interact with underlying firmware more or
> > less to be functional (power control, interrupt handling, etc.). So
> > giving a memory map does not eliminate the necessity of interactions with
> > firmware anyway.
>
> This isn't entirely true. Most of OS use their own firmware-independent
> drivers for most devices.

For device drivers, yes. For other things, not always. For instance, on Alpha, 
you need to use the firmware to enter the privileged mode. AFAIK, no other 
choice.

From my point of view, the conclusion should be based on whether a boot loader 
may want to provide a memory map different from what firmware thinks. If yes, 
we have a good reason to make it required. If no, not much.

> > Seemingly, someone made a bad change on the draft, so the information is
> > lost:
> >
> > http://grub.enbug.org/MultibootDraft?action=diff&rev2=23&rev1=22
> >
> > Hollis's idea was to use the same format as for modules to give
> > information about an OS image. A part of this change must be reverted. It
> > is wrong to adopt the spec to the implementation.
>
> It's ok with me. Quick look through the code suggests that probably
> kernel tag is created with type MODULE and that it also has an
> additional field type. I will check it tomorrow but it looks like a bug
> somewhere

Hmm.

> And what about encoding?

Fine for me.

Regards,
Okuji

Re: multiboot2

[phcoder]

Yoshinori K. Okuji wrote:
> On Tuesday 07 April 2009 10:18:30 phcoder wrote:
>> Yoshinori K. Okuji wrote:
>>>>> 1) double the size of flags. 8 features per category seems to be few.
>>> I do not agree on this. As you can see, most bits are still undefined
>>> after over 10-year usage of the Multiboot Specification. I do not want to
>>> change it without any real issue.
>> The difference is that multiboot2 is meant to be portable
> 
> Yes, but so?
On some platforms the number of features may be bigger
> Not really. Even with the most strict spec possible, it is always possible to 
> depend on implementation details which are not part of the spec. So, if an OS 
> image does boot only with some implementations, it is a fault in the OS 
> image, and the OS image should be fixed.
> 
I agree but specification should make such things less likely
>>>>> 6) memory map. "<!> Tags of this type should be omitted on
>>>>> architectures where the OS is able to retrieve this information from
>>>>> firmware. (Doing do will encourage OS portability across bootloaders,
>>>>> and simplify GRUB development and maintenance.) "
>>>>> This contradicts the goal of easier OS developement and may result in
>>>>> semi-compatible OS and bootloaders. Additionally I think that
>>>>> eliminating the necessity of use of firmware from OS is a good thing
>>>>> and allows easier porting between architectures differing only by
>>>>> firmware
>>> It is hard for me to say which is better.
>>>
>>> In reality, every OS needs to interact with underlying firmware more or
>>> less to be functional (power control, interrupt handling, etc.). So
>>> giving a memory map does not eliminate the necessity of interactions with
>>> firmware anyway.
>> This isn't entirely true. Most of OS use their own firmware-independent
>> drivers for most devices.
> 
> For device drivers, yes. For other things, not always. For instance, on Alpha, 
> you need to use the firmware to enter the privileged mode. AFAIK, no other 
> choice.
I don't know about alpha but on i386 cpu kernel needs only 4 things from 
  the bootloader to be totally firmware-independent: memory map, 
framebuffer info, rsdp and smbios address. So I propose to add tags for 
3 last things and make memory map required. This would encourage 
creation of OS working on all branches of i386 including coreboot
I think on many platforms it's possible to pass some number of 
parameters to make it firmware-independent too
> 
> From my point of view, the conclusion should be based on whether a boot loader 
> may want to provide a memory map different from what firmware thinks. 

Badram? Creepy firmwares?

>>> Seemingly, someone made a bad change on the draft, so the information is
>>> lost:
>>>
>>> http://grub.enbug.org/MultibootDraft?action=diff&rev2=23&rev1=22
>>>
>>> Hollis's idea was to use the same format as for modules to give
>>> information about an OS image. A part of this change must be reverted. It
>>> is wrong to adopt the spec to the implementation.
>> It's ok with me. Quick look through the code suggests that probably
>> kernel tag is created with type MODULE and that it also has an
>> additional field type. I will check it tomorrow but it looks like a bug
>> somewhere
> 
> Hmm.
> 
Implementation in grub2 matches neither version of the draft.
>> And what about encoding?
> 
> Fine for me.
I updated the multibootdraft
> 
> Regards,
> Okuji
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: multiboot2

[Vladimir 'phcoder' Serbinenko]

On Sat, Apr 11, 2009 at 8:56 PM, phcoder<phcoder@gmail.com> wrote:
> Yoshinori K. Okuji wrote:
>>
>> On Tuesday 07 April 2009 10:18:30 phcoder wrote:
>>>
>>> Yoshinori K. Okuji wrote:
>>>>>>
>>>>>> 1) double the size of flags. 8 features per category seems to be few.
>>>>
>>>> I do not agree on this. As you can see, most bits are still undefined
>>>> after over 10-year usage of the Multiboot Specification. I do not want
>>>> to
>>>> change it without any real issue.
>>>
>>> The difference is that multiboot2 is meant to be portable
>>
>> Yes, but so?
>
> On some platforms the number of features may be bigger
Additionally this format is hard to extend in cross-platform way.
Let's say we define new header on powerpc which takes bytes x to x+10
and a tag for i386 which takes bytes x to x+12 then we want to define
a new crossplatform tag. Where to we put it? Why not just use the same
format for multiboot header and multiboot info? It will make the job
of bootloader easier (handling one format instead of 2).
>>
>> Not really. Even with the most strict spec possible, it is always possible
>> to depend on implementation details which are not part of the spec. So, if
>> an OS image does boot only with some implementations, it is a fault in the
>> OS image, and the OS image should be fixed.
>>
> I agree but specification should make such things less likely
Recently we experienced the problem with OSes assuming different
details about specification. Of course it's bugs but bugs which are
difficult to find. Standard is here to decrease developpement time,
not increase it.
>>>>>>
>>>>>> 6) memory map. "<!> Tags of this type should be omitted on
>>>>>> architectures where the OS is able to retrieve this information from
>>>>>> firmware. (Doing do will encourage OS portability across bootloaders,
>>>>>> and simplify GRUB development and maintenance.) "
>>>>>> This contradicts the goal of easier OS developement and may result in
>>>>>> semi-compatible OS and bootloaders. Additionally I think that
>>>>>> eliminating the necessity of use of firmware from OS is a good thing
>>>>>> and allows easier porting between architectures differing only by
>>>>>> firmware
>>>>
>>>> It is hard for me to say which is better.
>>>>
>>>> In reality, every OS needs to interact with underlying firmware more or
>>>> less to be functional (power control, interrupt handling, etc.). So
>>>> giving a memory map does not eliminate the necessity of interactions
>>>> with
>>>> firmware anyway.
>>>
>>> This isn't entirely true. Most of OS use their own firmware-independent
>>> drivers for most devices.
>>
>> For device drivers, yes. For other things, not always. For instance, on
>> Alpha, you need to use the firmware to enter the privileged mode. AFAIK, no
>> other choice.
>
> I don't know about alpha but on i386 cpu kernel needs only 4 things from
>  the bootloader to be totally firmware-independent: memory map, framebuffer
> info, rsdp and smbios address. So I propose to add tags for 3 last things
> and make memory map required. This would encourage creation of OS working on
> all branches of i386 including coreboot
What about reserving a tag which will contain a copy of smbios anchor
and another for containing a copy of rsdp?
> I think on many platforms it's possible to pass some number of parameters to
> make it firmware-independent too
>>
>> From my point of view, the conclusion should be based on whether a boot
>> loader may want to provide a memory map different from what firmware thinks.
>
> Badram? Creepy firmwares?
Implementing memory map passing from bootloader side is cheap -
bootloader needs to know it anyway.
>>
>> Regards,
>> Okuji
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> --
>
> Regards
> Vladimir 'phcoder' Serbinenko
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git