grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IA64 port


From: tgingold
Subject: Re: IA64 port
Date: Tue, 29 Jan 2008 11:31:21 +0100
User-agent: Internet Messaging Program (IMP) 3.2.8

Quoting Robert Millan <address@hidden>:

> On Tue, Jan 29, 2008 at 06:12:52AM +0100, Tristan Gingold wrote:
> > > Have you checked if this trick works on other ports?  Maybe it'd be a
> good idea
> > > to merge this first.
> >
> > I don't really understand what do you mean by 'works on other ports'.  It
> is
> > designed to be an optionnal feature used only by ia64.  Nothing IA64
> specific
> > and other ports may use it.  If we go this way, it would be good to
> slightly
> > improve it.
>
> I suggest you just make sure it'll be usable on other ports in case a need
> arises, without going out of your way to support it.

Sure.  I won't forget other ports.  Anyway, there shouldn't be arch specific
code in this trick.

> > > > +GRUB_MOD_INIT(linux_normal)
> > > > +{
> > > > +  (void) mod; /* To stop warning.  */
> > > > +  grub_register_command
> > > > +    ("linux", grub_normal_linux_command,
> > > > +     GRUB_COMMAND_FLAG_BOTH | GRUB_COMMAND_FLAG_NO_ARG_PARSE,
> > > > +     "linux FILE [ARGS...]",
> > > > +     "Load a linux kernel.", 0);
> > > > +
> > > > +  grub_register_command
> > > > +    ("initrd", grub_normal_initrd_command,
> > > > +     GRUB_COMMAND_FLAG_BOTH | GRUB_COMMAND_FLAG_NO_ARG_PARSE,
> > > > +     "initrd FILE",
> > > > +     "Load an initrd.", 0);
> > > > +
> > > > +  grub_register_command
> > > > +    ("module", grub_normal_cmd_module,
> > > > +     GRUB_COMMAND_FLAG_BOTH | GRUB_COMMAND_FLAG_NO_ARG_PARSE,
> > > > +     "module FILE [ARGS...]",
> > > > +     "Load a Multiboot module.", 0);
> > >
> > > Multiboot module loader in linux_normal.mod ?
> >
> > Well, well well.  Long question :-)
> >
> > Ia64 doesn't really fit in multiboot: it's a full 64 bits processor,
>
> But there's multiboot2.

Right.

> > there
> > may be no room for an header in the 8KB (or you have to waste a lot of
> memory
> > to keep alignment), no room for EFI pointers in the header and no Ia64 OS
> > uses it.  Well this were my conclusion when I read MB specs.
>
> Does this affect only EFI, or ia64 in general (e.g. ia64-coreboot, when that
> exists) ?

It's IA64 indeed.

> Also note the string "Load a Multiboot module." is present.
>
> If this is not multiboot, I'd suggest renaming the command to avoid name
> collisions (not only if multiboot is added later, but also user confusion).

Ok, I will rename the command and change the string, so this issue will be
closed.

> > > > diff -ruNp -x '*~' -x CVS grub2.orig/util/ia64/efi/elf2pe.c
> grub2/util/ia64/efi/elf2pe.c
> > > > --- grub2.orig/util/ia64/efi/elf2pe.c   1970-01-01 01:00:00.000000000
> +0100
> > > > +++ grub2/util/ia64/efi/elf2pe.c        2008-01-28 16:29:58.000000000 
> > > > +0100
> > [...]
> > >
> > > This utility seems to be usable on i386 too?  In that case, better to put
> it
> > > outside ia64/ dir?
> >
> > It should work on i386 too, but not tested.
> > I have written this utility for my port of EFI and adapted the style for
> > grub.  It may be nice to share this code with i386 but not really required
> > now IMHO.
>
> util/i386/efi/grub-mkimage.c already generates PE, right?  Why a different
> way to handle this?  Sound like it'd be more consistent to either use elf2pe
> on both or share the same grub-mkimage.  What do you think?

Having only one implementation is for sure a goal.  But there are many
differences between the two implementations:

* grub-mkimage can only handle PE and I386.
* grub-mkimage can put modules image in a section.
* elf2pe can generate PE and PE+ and read I386 or IA64 ELF.

Enhancing grub-mkimage is not a small work as there are a lot of 32 bits types.
And in any case we have to test the two implementations (doable).

In my opinion, there is no need to hurry here.  The both implementations work,
they do slightly different job, do not require maintainance and we can do
the merge later.

Tristan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]