Re: grub2 multiboot for ppc and system initalization

[Marco Gerards]

Noah yan <address@hidden> writes:

>> Right.  Have you considered just waiting for multiboot 2 instead of
>> using a standard that is not a standard?  I assume multiboot 2 will be
>> there in some months or so...
>
> currently, it is enough that grub2 can load a kernel and jump to it (whether
> multiboot or not), saving efforts for coding in low-level devices, fs and
> open firmware. When grub2 and multiboot is ready, we definitely want
> to make it multiboot compliant. we also hope that network support is
> available in grub2 soon.

Both are actively being worked on.  Both can take some time.

> This is just my thoughts, and other guys from polaris developers may have
> other comments.

Sure, they can tell us.  Although I have no idea what the differences
between the projects are.

>> Oh, right.  It is something we can think about for multiboot 2.  The
>> main idea behind multiboot is providing information the kernel can not
>> get in another sane way or do things otherwise not really possible.
>> So that is what you have to keep in mind.
>
> That is good, but to use them will make the kernel not to be loaded by other
> non-multiboot loader (I am not 100% confident of this comment). So in
> multiboot standard, it would be great that the mulitboot-compliant kernel
> can be standardalone (if posibble).

Agreed, if something can be implemented according to the standard it
should work on other implementations of the standard.  If one portion
of the standard can be interpreted in multiple ways, the section
should be clarified.  But for now we just have to wait for the
standard because it does not exist yet. ;-)

> If you really have requirements for the new multiboot or problems with
> GRUB 2, please tell us. :-)
>
> Hum, I do have problems and questions currently. I tried to cross-compile
> the grub2 on a solaris x86 for ppc architecture and cannot make it.
> It seems that some codes use standard system and libc headers that cause the
> compilig fail. I clean some of them (such as stdint.h to types.h,
> alloca.hto grub_alloca.h), but I cannot clean the code that is
> generated by yacc on
> normal.py, so is grub2 going to clean up those usage?

How did you cross-compile?  If it is the bison code, I'll certainly
have a look at it.  I usually use cross-compiling myself, although I
need to setup a new cross-compiler again...

> On my mahcine(PowerMac G4) that have two IDE disks, the grub ls command
> lists some devices, such as ide@, (hd,0), ... (hd, 5), (ultra0,0), ...
> (ultra0, 5), (ultra1, 0), (ultra1, 1), ....  and I can access the "hd"
> device and fs (they are ext2), but I cannot access the second one, which has
> a Solaris2 partiton with solaris disklabel, is the ultra1 the second disk in
> the list output? Is the solaris disk label supported currently so that I can
> access via something like (hd1, 0, a)?

Right, I see the issue.  Solaris disk labels are supported AFAIK, but
not recursively.  I think there are many similar examples just like
this one.  I will add this to the todo list so we will not forget
about this.  It is important to do this in a generic way...  I'll
contact you about this later, but my todo is a bit full now. ;-)

--
Marco