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: [PATCH] memdisk plus lnxboot extension
Date: Tue, 22 Jan 2008 20:53:41 +0100	[thread overview]
Message-ID: <20080122195341.GA21526@thorin> (raw)
In-Reply-To: <ca0f59980801220917m5d1072a2ge14323aa28af712f@mail.gmail.com>

On Wed, Jan 23, 2008 at 01:17:43AM +0800, Bean wrote:
> On Jan 23, 2008 12:51 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > I don't like this very much.  We don't have grub-mkimage options to concatenate
> > it with boot.img, so why with lnxboot.img ?
> 
> The reason for new option is that the length of core.img needs to
> stored in lnxboot.img. Previously, i calculate the size using
> information in core.img header, but now there is issue, for example,
> 
> 1.
> kernel lnxboot.img
> initrd core.img
> 
> 2.
> cat lnxboot.img core.img > grub2.bin
> kernel grub2.bin
> initrd memdisk
> 
> 1 and 2 looks the same to lnxboot header, it can't decide initrd is
> used as memdisk or core.img. However, 1 may not be that useful after
> all, we can disable this kind of usage.

I didn't know you had 1 in mind.  Yes, I think it's better to restrict us
to 2 for now.  I don't really see a big benefit in 2 vs just using
"grub-mkimage -m", but I suppose if it's not too intrusive it doesn't harm.

> > Also, I can only think of very specific situations in which this interface
> > would be useful (that is, when firmware has only a linux loader).  It makes
> > sense to me as a compatibility layer, yes.
> >
> > But it seems you want it as a general-purpose option; for that, why not make
> > it saner like multiboot?  I don't think it's a good idea to compromise our
> > boot semantics because of the ones legacy Linux has.
> 
> is multiboot support memdisk or something similar ?

I'm not very familiar with multiboot, but it supports modules (an arbitrary
number of them, I think).  Then again, we still need a use case before adding
a feature.  The obvious use case for having lnxboot is booting from firmware
that only supports booting Linux, but for other stuff I still don't see it.

I mean, the initial purpose of memdisk was that you could _embed_ data in
core.img itself.  Using it as a loader feature sounds a bit contradictory to
me... perhaps if you explain what situations do you have in mind where this
would be helpful, I'd understand your point better.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)



  reply	other threads:[~2008-01-22 19:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-29  9:05 [PATCH] memdisk plus lnxboot extension Bean
2007-12-30 13:48 ` Robert Millan
2008-01-20 23:24   ` Robert Millan
2008-01-22  4:25     ` Bean
2008-01-22 13:57       ` Robert Millan
2008-01-22 16:22         ` Bean
2008-01-22 16:51           ` Robert Millan
2008-01-22 17:17             ` Bean
2008-01-22 19:53               ` Robert Millan [this message]
2008-01-23  8:54         ` Marco Gerards
2008-01-23 16:18           ` Bean
2008-01-23 19:01             ` Bean
2008-01-23 19:14               ` Robert Millan
2008-01-23 19:24                 ` Bean
2008-01-23 20:15                   ` Robert Millan
2008-01-23 21:04                     ` Bean
2008-01-23 21:15                       ` Robert Millan
2008-01-24  3:40                         ` Bean
2008-01-24 11:32                           ` Robert Millan
2008-01-24 11:49                             ` Bean
2008-01-24 14:25                               ` Robert Millan
2008-01-24 14:57                                 ` Bean
2008-01-24 15:16                                   ` Robert Millan
2008-01-24 16:55                                 ` Robert Millan
2008-01-24 17:04                                   ` Bean
2008-01-24 17:21                                     ` Robert Millan
2008-01-24 18:06                                       ` Marco Gerards
2008-01-24 21:23                               ` Yoshinori K. Okuji
2008-01-23 19:10             ` Robert Millan
2008-01-23  8:48       ` Marco Gerards

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=20080122195341.GA21526@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.