From: Per Lundberg <[EMAIL PROTECTED]>
Subject: Re: Graphics mode support
Date: 10 Jan 2000 20:04:19 +0100
> No. I will have to think a while about this. I'll send a diff for you
> later this week. Do you think it will make it for 0.7?
I'm not sure. If it is added into 0.7, GRUB 0.6 will have to support
it. This will delay the release, maybe considerably. So the
requirement is that you (or someone) write the code for GRUB soon. I
can wait for a few months, since netboot will not complete so fast,
but I don't want to wait for several months.
> BTW, I really think we should make the Multiboot standard more easily
> extendible.
Please call it "the Multiboot Specification". I and Erich agreed
that the word "standard" was inappropriate.
> This makes the data structure it a little more difficult to parse and
> create, but the flexibility makes it worthwhile IMO. The downfall in
> this case is that it breaks the compatibility with existing
> systems. But I think the advantage is so big that it's worth it. What
> do you think?
That's a good idea. I know there is a dirty but backward-compatible
way, that is, adding extensions into another area, as the BOOTP
protocol. The BOOTP format contains the backward-compatible
information in the first 236 bytes and the vendor extensions right
after it. The vendor extension is just like what you said.
Perhaps some people like this way, because they don't need to modify
their kernels until they want to use the extensions. However, I don't
like it, because it is not elegant very much. But backward
compatibility is very important, of course.
Therefore, it would be better to support the two formats by using
different magic numbers for them. So if the magic number in a kernel
is 0x1BADB002, GRUB would pass the old-style information structure to
the kernel, and if the magic number is 0xWWXXYYZZ, it would use the
new-style information structure. Does that sound good?
(Of course, I don't want to make such a radical change in 0.7,
though.)
----------------------------------------------------------------------
OKUJI Yoshinori <[EMAIL PROTECTED]> ^o-o^
http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English) m /
