Re: TODO list for 0.92

[Christoph Plattner]

I have not studied the multiboot interface in GRUB, but the idea
sound good using text (ASCII) to pass information, and in case
of addresses, hex valuses sound also very good.

So a address and len can be given to define a module, then pass
over the module parameter line. So one module can be given as
one line like (ONLY EXAMPLE)

grub> module hallo.mod xxx=01233 aaa

will be passed as string to the OS like

"name=hallo.mod base=0x00320000 len=0x00000400 xxx=0123 aaa"

(may be hallo.mod under quotes, etc...)
The primary parser has to look at the first 3 fields, the module
code itself can have access to the rest...

Best regards
Christoph


"Yoshinori K. Okuji" wrote:
> 
> 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
> 
> _______________________________________________
> Bug-grub mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-grub

-- 
-------------------------------------------------------
private:        address@hidden
company:        address@hidden