Re: Solaris assumptions

[phcoder <phcoder@gmail.com>]

My previous letter was scarce on details. Here some more comments:
grub1 and grub2 if they detect an elf executable with AOUT_KLUDGE bit 
set they follow the specification and load the file using addresses from 
multiboot header. grub-solaris however in the same case uses elf 
headers. This error has been known to sun for some moment but for an 
unknown reason they don't fix their multiboot header.
2) Some kind of in-kernel debugger tries to open the kernel file. For 
ths it uses the zeroth argument from command line and assumes it's a 
solaris filename on disk pointed by BOOTDEV. It doesn't work in many 
case e.g. if kernel is loaded with drive prefix
3) I made grub2 put mbi, cmdline and mmap before the protected mode heap 
. With this I'm able to boot solaris succesfully. If I use, however 
standard code it creates a range of nasty effects including out of 
memory error, kernel panic and triple fault
First two are entirely sun's fault but some kind of option to make grub2 
behave like grub-solaris is possible.
The third one is more controversial for already the fact that more OSes 
fall into this trap. Of course it's against specification but I feel 
like grub2 should be able to boot the same kernels as grub1. For a very 
list to avoid a flow of bug reports and to help in transitioning to 
grub2. These issues are fixed in multiboot2 because it doesn't use 
pointers anymore.
phcoder wrote:
> Hello, investigating Solaris/OpenSolaris/Pulsar kernel I found that it 
> makes assumptions which are false in grub2 environment. Now we should 
> decide what to do. Assumptions:
> 1) Bad multiboot header. AOUT_KLUDGE bit is set but no aout multiboot 
> fields. Actually the image is elf. I fixed it by just putting this bit 
> to zero in the binary. It's possible to add a workaround but it's 
> basically a sun's issue
> 2) solaris is able to open its own kernels file by the name from grub's 
> cmdline. It's also a bad assumption which is entirely sun's fault
> 3) mbi, cmdline and mmap are in low memory. These bits are discuttable. 
> Specification doesn't guarantee these parts to be on low memory however 
> different OSes assume that and it makes mapping memory much easier. If 
> we want to superseed grub1 we should use daChaac's memory management and 
> allocate the space for these parts on low memory


-- 

Regards
Vladimir 'phcoder' Serbinenko