On Thu, Jul 2, 2009 at 7:51 PM, Pavel Roskin<pro...@gnu.org> 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 > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
