All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [RFC] Multiboot ammendment: non-VBE video
Date: Fri, 1 Jan 2010 12:30:10 +0100	[thread overview]
Message-ID: <20100101113010.GA3692@thorin> (raw)
In-Reply-To: <4B389F6E.70902@gmail.com>

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	other threads:[~2010-01-01 11:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-01 15:37 [RFC] Multiboot ammendment: non-VBE video Vladimir 'phcoder' Serbinenko
2009-12-24 22:29 ` Robert Millan
2009-12-28 12:07   ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-01 11:30     ` Robert Millan [this message]
2010-01-02 18:26       ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-03 16:13         ` Robert Millan
2010-01-03 16:35           ` Isaac Dupree
2010-01-04 21:19             ` richardvoigt
2010-01-04 19:35           ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-07 18:45             ` Robert Millan
2010-01-07 20:18               ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-12 16:52                 ` Robert Millan
2010-01-12 16:54         ` Multiboot video in GRUB (Re: [RFC] Multiboot ammendment: non-VBE video) Robert Millan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100101113010.GA3692@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.