Re: Idea: Move kernel to upper memory

[Bean]

On Sat, Aug 30, 2008 at 8:40 PM, Robert Millan <address@hidden> wrote:
> On Fri, Aug 29, 2008 at 07:15:43PM +0800, Bean wrote:
>> Hi,
>>
>> The traditional memory is quite small, and is used by real mode apps.
>> By moving grub2 kernel to upper memory, it's possible to keep it after
>> dos started, and we can invoke grub2 service using interrupts. One
>> important usage is to provide disk related function to dos via int 13,
>> for example, loopback device, ata/usb disk or linux software raid. It
>> would also be possible to reenter grub2 at any time.
>>
>> I have thought of a method to implement this. First, we put kernel
>> code in a module kernel.mod. The platform initialization code is
>> separated and placed in startup.img. Startup.img would do things like
>> getting memory map, relocate real mode trunk and save the information
>> in a platform dependent structure. It then pass it to the first
>> module, which would be kernel.mod. kernel.mod relocates itself and
>> other embedded modules to upper memory, then calls the entry point for
>> further tasks.
>>
>> One advantage of this scheme is that symlist.c is not longer needed.
>> Kernel is a module, other module can use its exported function. And
>> platform dependent data and function, such as efi system table, x86
>> interrupt call, etc, can be passed using a structure.
>
> On one hand, I think being useful as a kind of "driver library" for DOS-based
> systems (specially FreeDOS) would be a cool thing.  Our hardware drivers
> would become more exposed and we could get more people to test them.
>
> On the other, I think we should be careful about going too much out of our
> way.  GRUB is a bootloader, and its main strength is that it works well at
> what it does.  For example, some have tried to make Linux work as a
> bootloader, but it doesn't work well, because it hasn't been built from
> the ground up for this purpose.
>
> Similarly, other projects strive to provide a free BIOS [1], like SeaBIOS.
> For the same reasons, I think SeaBIOS is better suited for being a BIOS than
> GRUB is.
>
> The first concern that comes to mind is how would GRUB coexist with the
> payload area which precisely starts at 0x100000.  But I expect we'd face
> many unexpected issues.
>
> Another approach with similar result could be to ditch the legacy interface
> and provide the glue that would allow FreeDOS to link directly with GRUB.
> Maybe that would be as much useful?
>
> [1] Not to be confused with a core initialization program, such as coreboot

Hi,

Yep, come to think of it, this method may be too complicated to be
useful.There are easier way to do similar thing.

Speaking of library, I think we can provide a dynamic library for core
grub2 function. Apps written properly can be executed in both native
os and grub2. For example:

int main()
{
  grub_printf ("Hello world\n");
  return 0;
}

gcc hello.c -o hello -lgrub2

-- 
Bean