Re: Solaris assumptions

[phcoder <phcoder@gmail.com>]

Correction: Third point goes away as it was revealed that it was enough 
to put these 2 structures in multiboot payload. Now fixed solaris kernel 
boots fine with latest svn+my elf fix. And the first two points are 
solaris bugs
phcoder wrote:
> 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