Re: [multiboot2] Tagged multiboot2 header

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

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

Robert Millan wrote:
> On Thu, Jan 21, 2010 at 12:49:55AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>> +@node Header tags
>> +@subsection General tag structure
>> +Tags constitutes a buffer of structures immediately following each other.
>> +Every structure has following format:
>> +
>> +@example
>> +@group
>> +        +-------------------+
>> +0       | type              |
>> +4       | size              |
>> +8-11    | optional          |
>> +        +-------------------+
>> +@end group
>> +@end example
>>     
>
> This looks fine.  Please go ahead with the proposed new layout.
>
> As for the addition of new fields for architecture / endianess, I wonder
> if it makes sense to continue supporting aout-kludge in Multiboot 2.  It
> seems that all of the projects interested in Multiboot use ELF natively
> themselves and shouldn't have trouble with it, whereas projects that don't
> use ELF are almost invariably proprietary OS and never showed any interest
> in Multiboot.
>   
There is at least one case where architecture fields is useful: amd64 vs
i386. if kernel is ELF64 we don't know if it expects to be started in
either i386 or amd64. An example is NetBSD which will certainly want to
keep compatibility with their own protocol which starts kernel in i386
mode. I think we need to allow 2 things:
1) start elf64 in i386
2) start with an entry point different from the one specified in ELF
header. For this we could split kludge header in 2 parts: loading and
entry point. This allows overriding ELF entry point. This way kernel can
have a separate entry point for multiboot.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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