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 -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
