[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [multiboot2] Tagged multiboot2 header

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [multiboot2] Tagged multiboot2 header
Date: Tue, 02 Feb 2010 00:22:00 +0100
User-agent: Mozilla-Thunderbird (X11/20091109)

Robert Millan wrote:
> On Thu, Jan 21, 2010 at 12:49:55AM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> address@hidden Header tags
>> address@hidden General tag structure
>> +Tags constitutes a buffer of structures immediately following each other.
>> +Every structure has following format:
>> +
>> address@hidden
>> address@hidden
>> +        +-------------------+
>> +0       | type              |
>> +4       | size              |
>> +8-11    | optional          |
>> +        +-------------------+
>> address@hidden group
>> address@hidden 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.

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]