grub-devel
[Top][All Lists]
Advanced

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

Re: Anyone willing to sponsor an ARC case for grub2?


From: Vladimir 'phcoder' Serbinenko
Subject: Re: Anyone willing to sponsor an ARC case for grub2?
Date: Tue, 30 Jun 2009 13:48:19 +0200

>
>  There's much that should be improved with respect to how zfs integrates
> with GRUB.
>
Ok. If you have time you can look at zfs and nestpart branches in my
repo (for grub2). I added the things like ls -l support and tab
completion. Comments are welcome
>
>  I've never had any love for $ZFS-BOOTFS. I was however unable to sell
> anyone on extending or abusing the multiboot structure to pass this up.
I thought of implementing something like $ZFS-BOOTFS but in a way to
use grub2 variable support
In would be sth like:
zfsinfo --solaris -s ZFS-BOOTFS (LABEL=rpool)/ROOT@/
multiboot ... $ZFS-BOOTFS
In this case zfsinfo can give back other useful info about zfs e.g.
Or
zfsinfo --objnum -s OBJNUM (LABEL=rpool)/ROOT@/
Currently normal way to specify root device is to do so on command
line. The fields in multiboot structure were defined as based on BIOS
and as such not easily usable by Operating System. Additionally grub2
can access the disks directly with ata.mod so it may not know about
BIOS disk numbering at all. Also on non-BIOS this data simply doesn't
exist at all. The command line has an advantage of being easily
user-modifiable. If you can propose a reliable unambiguous OS- and
booter-independent way to pass root device from grub to OS I would be
interested
Perhaps one can pass a command-line parameter like
root=poolname/address@hidden ?
This way it's clear and uses the same syntax as zfs mount.
>
>  Are you using a newer version of the structure?
I use the multiboot structure as defined in the latest multiboot specification
>
>>>  Since the menu changes significantly this will basically break all the
>>> legacy installers/upgraders and kill nevada for x86.
>>
>> We now have a scripting support both for lua and sh. Both advance now
>> and with proposed patches lua scripting would be able to create menu
>> on runtime listing all installed OSes.
>
>  If you're not familiar with the Solaris legacy installers, it's largely an
> organizational hair-ball due to the transition to opensolaris. At the moment
> no one is tasked with maintaining the code, we're not allowed to, or at
> least discouraged from touching it and we're not allowed to break it :) .
> However the clock is running out on them and I feel fairly confident that we
> can ignore this problem toward the end of year time-frame.
>
GRUB2 has a possibility of multiple scripting engines. Currenly they
are sh and lua. Legacy compatibility mode can be implemented the same
way then you will just need to add a "#!legacy" to the top of menu.lst
and make a symlink to it from grub.cfg (my zfs branch already supports
symlinks on zfs) but the price of such move is that you can't use
grub2 scripting and I feel like implementing legacy compatibility mode
is a waste of time. If you put autoscanning to grub.cfg then grub2
will simply ignore menu.lst and find installed OS itself. However I
don't know which organisational problems these approaches may be on
your side.
>>> I'm at peace with that,
>>> but this project can't be the one that drives that, so I'd suggest timing
>>> integration accordingly (this should roughly line up correctly if
>>> EFI drags GRUB 2 in).
>>
>> I think multiboot standard could be extended to pass SMBIOS/RSDP
>> pointer to payload. It would allow kernel to stay unaware if it runs
>> on EFI, BIOS or Coreboot. We're also creating multiboot2 standard
>> which is meant to be portable. We have sparc64 grub port and in my git
>> grub2 already parses big-endian volumes.
>
>  We've looked at GRUB 2 on SPARC/OBP, and since it can't eliminate OBP
I'm not sparc expert but if hardware drivers are similar to x86-pc,
hardware initialisation not difficult and we have documantation on it
grub2 can be made into firmware. As example you can look at Robert
Milan's i386-qemu port. We also started a yeelong port which in
perspective will be a firmware port. But I suppose this would be a
completely different ARC case



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git




reply via email to

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