[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Solaris assumptions
From: |
phcoder |
Subject: |
Re: Solaris assumptions |
Date: |
Tue, 03 Mar 2009 19:14:38 +0100 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090105) |
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