grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Multiboot ammendment: non-VBE video


From: Robert Millan
Subject: Re: [RFC] Multiboot ammendment: non-VBE video
Date: Fri, 1 Jan 2010 12:30:10 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Dec 28, 2009 at 01:07:10PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> Robert Millan wrote:
> > On Tue, Sep 01, 2009 at 05:37:11PM +0200, Vladimir 'phcoder' Serbinenko 
> > wrote:
> >   
> >> Hello. I'm implementing video part of multiboot specification.
> >> Currently the only defined interface is for providing VBE info. I
> >> propose following way to set fields if video is non VBE:
> >> vbe_control_info=0xffffffff
> >> When vbe_control_info is set to 0xffffffff all VBE-specific fields are 
> >> invalid
> >> vbe_mode set to 0xffff
> >> vbe_interface_seg=0xffff
> >> vbe_interface_off=0xffff
> >> vbe_interface_len=0xff
> >> vbe_mode_info points to structure similar to vbe_mode_info but with
> >> all vbe-specific fields set to zero. Remaining (valid) fields are
> >> (full structur is in include/grub/i386/pc/vbe.h)
> >>     
> >
> > This seems like one of these cases in which legacy gets in the way.  Why
> > don't we just replace the legacy structure with something that doesn't need
> > dummy fields?
> >   
> Actually it seems like we already define possible dummy fields if
> vbe_interface isn't available.

Yes.  That's the case for vbe_interface_* fields.  But extending this to
vbe_control_info and vbe_mode_info is backward-incompatible.

I don't object to backward-incompatible changes, but I would expect that
when we make one, we get the benefit of a clean, legacy-free interface.  In
this case we carry on with legacy baggage to archieve half-way backward
compatibility.

In purely practical terms, all of this only has a minimal effect.  GRUB Legacy
didn't implement these extensions, and GRUB 2 hasn't yet, so use of this
feature in loadees isn't widespread.  But it has a major impact when it comes
to reputation.  If we make incompatible changes in the text, we should be
honest about it.  I don't want people to think they can't rely on Multiboot
because its maintainers sometimes stretch the definitions in ways not
permitted by the text.

Since it's obvious we want to change something (rather than implement
VBE-specific extensions), I propose we start with:

-If bit 11 in the @samp{flags} is set, the graphics table is available.
+If bit 12 in the @samp{flags} is set, the graphics table is available.

at this point, we can change anything we like.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]