All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [RFC] Boot parameters and geometrical stability
Date: Fri, 5 Sep 2008 12:05:21 +0200	[thread overview]
Message-ID: <20080905100521.GC5220@thorin> (raw)
In-Reply-To: <48C05527.1020903@gmail.com>

On Thu, Sep 04, 2008 at 11:37:43PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
> >>> I assume you talk about GRUB loading itself;  what kind of information would
> >>> you pass from one GRUB to the other?
> >> Boot device,
> > 
> > Multiboot already handles that (although it's not reliable; I don't
> > think this feature should be used anyway).
> > 
> Feature in multiboot is hmm..: it gives bios device and grub supports
> also other devices.

Yes.  Besides, it's only an integer, which isn't able to reliably identify
a device.  That's why I don't think this feature should be used.

> > Which parameters do you have in mind?
> > 
> I thought of it more like about instruction like: boot from strange
> place or enter debug mode in early stage.

You don't need additional parameters for that.  Since both loader and loadee
can take user input, user can tell the loadee to enter debug mode instead of
the loader (press 'c', then set debug=something, etc).

> > Doesn't PXE already handle this?
> > 
> I'm not really familiar with it. Does it support multiple servers.

Neither am I.  I think we should have a clear idea on what our requirements
for PXE are before discussing if we need to use boot parameters for it.

> But still for me this feature is just an idea. I'm still not
> persuaded myself whether it's needed.

Maybe it's a good idea, or maybe it's not useful for anything.  I think first
of all we should exactly know what it is needed for.  IMHO, we should be
careful about adding interfaces just for the sake of having them.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."



      reply	other threads:[~2008-09-05 10:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-03  9:50 [RFC] Boot parameters and geometrical stability phcoder
2008-09-03 10:36 ` Robert Millan
2008-09-03 12:31   ` phcoder
2008-09-03 16:51     ` Vesa Jääskeläinen
2008-09-03 17:17       ` phcoder
2008-09-03 17:49         ` Vesa Jääskeläinen
2008-09-03 18:36           ` phcoder
2008-09-03 19:07             ` Vesa Jääskeläinen
2008-09-03 19:23               ` phcoder
2008-09-04 19:37           ` Robert Millan
2008-09-04 21:40             ` phcoder
2008-09-05  9:58               ` Robert Millan
2008-09-04 19:33     ` Robert Millan
2008-09-04 21:37       ` phcoder
2008-09-05 10:05         ` Robert Millan [this message]

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=20080905100521.GC5220@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.