Re: Some ideas about new features of grub

[Pavel Roskin <proski@gnu.org>]

On Thu, 2009-07-02 at 16:48 +0800, Bean wrote:
> Hi,
> 
> Here are some of my ideas about the new features of grub.
> 
> Move kernel to a module.
> This make it possible to relocate the kernel. For example, we can use
> it to move grub-pc to upper memory, and free conventional memory for
> use by real mode os such as MS-DOS. grub can resides in memory even
> after os take overs, and we can invoke it through interrupt hooks.

I don't care about MS DOS.  Other OSes should not need GRUB.  If you
want GRUB to be a supervisor or a microkernel, it's better that GRUB
loads them instead of incorporating their functionality.

The only reason for GRUB to _be_ a supervisor or a microkernel would be
to implement some kind of TPM, and I don't think we should spend
development effort on that unless were can be sure that it won't be used
against our users.

> LUA integration.
> LUA is quite powerful, it's more suitable to do complicated task than
> sh script. For example, we can use it to detect os at runtime,
> implement simple commands, or draw the graphic menu.

Yes, I think LUA improvements should continue.  We may switch to a LUA
implementation of grub.cfg at some point.

> Read/Write file system support
> We can implement two kind of fs drivers. The boot time driver is
> read-only, but after entering normal mode, we can optionally load
> another driver for write support. This approach has been used by EFI.
> For example, it has a default FAT driver, but you can also load an
> extended FAT driver
> later.

I think it's pure featuritis.  There is no reason for a bootloader to
write to filesystems except to store it's state, which is already
implemented.  What would GRUB write?  Implementing and maintaining full
featured drivers would take a lot of effort.  I'd rather see someone
implement UUIDs for all filesystems.

> Disk emulation.
> Now that it has drivemap command, we can extended it to map hard disk
> or cdrom image file, roughly equivalent to the memdisk of syslinux.

Hard drives and CD-ROMs are usually large and would take a lot of space
in memory that would need to remain allocated.  I think we need a strong
case to start that effort.

I'd rather see an effort to support CD-ROM and other ATAPI devices
without disrupting BIOS access to the hard drives and floppies.  We also
need AHCI support.

-- 
Regards,
Pavel Roskin