Re: [PATCH] Handling command line option for core.img and g2ldr

[Bean]

On Thu, Feb 28, 2008 at 11:33 PM, Robert Millan <address@hidden> wrote:
>
>  [ readding CC to grub-devel ]
>
>
>
>  On Thu, Feb 28, 2008 at 08:26:12PM +0800, Bean wrote:
>  > On Thu, Feb 28, 2008 at 6:18 PM, Robert Millan <address@hidden> wrote:
>  > > On Mon, Feb 25, 2008 at 02:10:46AM -0500, Pavel Roskin wrote:
>  > >  > Quoting Bean <address@hidden>:
>  > >  >
>  > >  > >This patch allow passing command line options to core.img or g2ldr:
>  > >  >
>  > >  > Isn't it an overkill?  When do you think it would be really needed in
>  > >  > practice?  I don't feel good about adding code just because we can.
>  > >
>  > >  I agree with Pavel.  Size is in init.c is very important.  The MBI 
> structure
>  > >  already contains the info for GRUB to figure out $prefix and $root, and 
> other
>  > >  variables can be set by user after GRUB has started.  So what is the 
> purpose
>  > >  of an additional interface?
>  >
>  > The problem of MBI boot device is that it's quite limited, it can only
>  > represent (hdx,y,z) and (fdx,y,z). But in fact, the root device can be
>  > of other form. For example, cd boot device (cd0). The current
>  > implementation use some sort of heuristic to decide whether it's cd
>  > drive, but it's not guaranteed to work. Moreover, if we use ata
>  > instead of biosdisk, then the boot device is (atax,y,z), which can't
>  > be represented properly. Also , it couldn't handle the situation where
>  > root device is not the same as boot device.
>
>  There are worse situations in fact (in that they're more common), like RAID
>  and LVM drives (which can be the boot device too).
>
>  But I don't think we need parser code for that.  The path part of the prefix
>  (/boot/grub, but sometimes /grub) is already hardcoded in by grub-mkimage, so
>  why not extend that to storing the whole path?  It's just a few bytes more
>  (typically 4), which is much less than code to parse cmdline params.

I think this could work, it actually avoid a lot of trouble by storing
the device name as well. A little setback is that we need to create
different core.img for different boot device, perhaps we can allow
both absolute and relative boot device. if the boot device starts with
(, then it's absolute, otherwise it's relative, we can get the full
boot device using current method.

-- 
Bean