[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multiboot2: make multiboot header optional
From: |
Marco Gerards |
Subject: |
Re: multiboot2: make multiboot header optional |
Date: |
Sat, 02 Dec 2006 17:18:10 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
"Yoshinori K. Okuji" <address@hidden> writes:
> On Saturday 25 November 2006 04:35, Hollis Blanchard wrote:
>> > I don't like it very much. My first draft was exactly like this. But,
>> > after some discussion in the IRC, I decided to revert my idea, because
>> > specifying so many parameters by hand really sucks. It is too
>> > error-prone.
>>
>> Bits are less error-prone?
>
> Less typing is less error-prone.
What is the problem with typing? I do not think this is really
complex? And this is just in the initial stage of the implementation
of an operating system. I don't think this is a problem, I think
something that is clear from the context, which is the case in Hollis'
proposal will prevent such errors.
>> How about this:
>> MB_START_TAGS()
>> MB_LOADADDR(0x1234)
>> MB_ENTRYADDR(0x1234)
>> MB_END_TAGS()
>
> How to abbreviate information does not matter. When one implements an OS, she
> must put the definition at somewhere anyway. Even if we provide a sample
> implementation, not all people won't use it, because there are various
> assemblers and compilers. For example, if our example is for GNU as, nasm
> users won't use it. So the spec must be simple.
Can't this be done with nasm?
--
Marco
- Re: multiboot2: make multiboot header optional, Marco Gerards, 2006/12/02
- Re: multiboot2: make multiboot header optional,
Marco Gerards <=
- Re: multiboot2: make multiboot header optional, Marco Gerards, 2006/12/04
- Re: multiboot2: make multiboot header optional, Hollis Blanchard, 2006/12/05
- Re: multiboot2: make multiboot header optional, Yoshinori K. Okuji, 2006/12/05
- Re: multiboot2: make multiboot header optional, Hollis Blanchard, 2006/12/07
- Re: multiboot2: make multiboot header optional, Yoshinori K. Okuji, 2006/12/12