Re: TODO list for 0.92

[Yoshinori K. Okuji]

At Mon, 04 Feb 2002 13:09:12 -0800,
address@hidden wrote:
> Oh well, that and maybe other Multiboot info bits being passed as
> text/human-readable is food for thought.  I've been getting more
> opinionated about such things as I go further into working on my own
> OS project.  I'm kind of imagining going back to an ultra-simple MB
> info block with just lower/upper memory (i.e. the info you need RIGHT
> AWAY before you can even, say, allocate a stack), then a bunch of text
> bits that are optional.

I must admit that it is cool. ;)

In past discussions on a new generation of Multiboot Specification, we
were talking about how to represent information passed to an OS
image. What I and Per Lundberg proposed was a list of tagged items, as
used very often in network protocols, like this:

+-------+------+-------+-------+------+-------+    +-----+
| type0 | len0 | data0 | type1 | len1 | data1 | ...| END |
+-------+------+-------+-------+------+-------+    +-----+

My idea was to make the spec easier to extend and collect memory
regions used for data into a single area, while the current spec
requires a fixed structure regardless of how many options are really
passed, and memory regions for the information may be distributed
sparsely because it includes pointers (so it is rather difficult to
find out what memory region is available for the OS image itself).

The demerit in this proposal is that the format of each data varies
among types - you must define how to represent information on a given
type, and it is not necessarily human-readable (besides hex dump).

I think, however, this proposal has an advantage over yours, when
passing already-defined-binary-structures, such as VBE's. Text is good
when passing linear data structures, but it is not suitable for
composites, such as binary trees.

Of course, it is a balance problem, as text and binary are
exchangeable with various techniques (e.g. Base64, XML, and hex
dump).

> I feel tempted to switch it to hex, especially after trying it out and
> finding it much easier to interpret.  Would you or anyone else you
> know of care?

I agree with you. That makes the information consistent.

Thanks,
Okuji