Re: Some ideas about new features of grub

[Vladimir 'phcoder' Serbinenko]

On Thu, Jul 2, 2009 at 7:51 PM, Pavel Roskin<address@hidden> wrote:
> 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.
>
This isn't about just msdos. Disk emulation may need this design
change. It may be used in future for booting proprietary OSes from
disk images.But it shouldn't matter for free OSes which either support
initrd in some form or such feature can be added to them. I wouldn't
spend a lot of effort to implement something which is useful only for
proprietary OSes. Leaving entire grub is perhaps a bit of overkill. I
would prefer another approach: compile kernel twice: once as normal
kernel and another time as kernel for persistent grub. Modules can be
the same. This approach has an advantage of not increasing core.img
size (we already not too far from the wall) while implementing kernel
feature. We should take more care about core.img size
But another reason
>> 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.
>
Even if LUA is great I don't agree with its usage as default. LUA is
under a bit different copyright license. While it's ok for it to be
incorporated and used you should be able to use grub even without LUA.
Additionally at least some feature aren't too hard to implement in sh
and I find sh more appropriate for menu generation.
>> 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 agree. I have given this a thought and conclusion was that writing
isn't used enough to be well tested and so to leave an "experimental"
stage. And experimental writing driver is a risk of FS corruption. I
don't want to sacrifice reliability for not-so-needed features.
Additionally again it seems like a waste of time. This being said
you're free to implement it (it's your free time) and put it somewhere
else or perhaps in grub trunk but under a separate directory/branch
and which must be explicitely compiled.
> 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.
>
Todays RAM is usually big enough. This feature would mainly be used to
boot install images and not normal OSes and install image + memory
needed for installer usually fits 1GiB. On the other hand small
laptops and netbook usualy have no CD. It would also be possible not
to store the image in RAM and read it directly from disk if grub's
drivers are left in memory one way or another. But this way there are
2 disk drivers working in the same time: OS and grub's one and this
leads to corruption. Fortunately DOS-like OS use BIOS and grub can
intercept it too. In this case however grub will conflict with dos
extenders. Protected-mode OSes would ignore disk emulation unless
special driver is used. In this case it would duty of this driver to
ensure no other disk driver is used when grub is called. This is an
important performance hit. And again this is mainly useful for
proprietary OSes. To support windows you can do it by writin windows
driver and porting freeldr to grub. For Mac OS X it caan be
implemented using xnu_ramdisk and some program to mount image and
chroot to it. And there is no point in supporting other proprietary
OSes
> I'd rather see an effort to support CD-ROM and other ATAPI devices
> without disrupting BIOS access to the hard drives and floppies.
You can't have 2 disk drivers operation on same device without taking
some risk. I would prefer ehci driver and floppy driver if someone
still needs them
>  We also
> need AHCI support.
>
Isn't it already the case?
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git