[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some ideas about new features of grub
From: |
Marco Gerards |
Subject: |
Re: Some ideas about new features of grub |
Date: |
Fri, 31 Jul 2009 10:18:50 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Pavel Roskin <address@hidden> writes:
> 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.
Please, don't. I never had objections against lua, but lua should not
silently take over.
>> 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.
Agreed.
>> 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.
Right. Although I do not mind if a separate module is added for
this. Given that the person who adds it will maintain it properly.
--
Marco
Re: Some ideas about new features of grub, Robert Millan, 2009/07/04
- Re: Some ideas about new features of grub, Bean, 2009/07/04
- Re: Some ideas about new features of grub, Robert Millan, 2009/07/07
- Re: Some ideas about new features of grub, Pavel Roskin, 2009/07/08
- Re: Some ideas about new features of grub, Robert Millan, 2009/07/10
- Re: Some ideas about new features of grub, BandiPat, 2009/07/10
- Re: Some ideas about new features of grub, Bean, 2009/07/11
- Re: Some ideas about new features of grub, Michal Suchanek, 2009/07/11
- Re: Some ideas about new features of grub, Colin Watson, 2009/07/11
- Re: Some ideas about new features of grub, Robert Millan, 2009/07/11