At Mon, 04 Feb 2002 13:09:12 -0800, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
