Re: Some ideas about new features of grub

[Pavel Roskin <proski@gnu.org>]

On Thu, 2009-07-02 at 21:38 +0200, Vladimir 'phcoder' Serbinenko wrote:

> > 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

OK, whoever wants to implement that will need to provide a use case.

> >> 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.

I really like the idea of looking for the kernels on the fly.  If we can
do it in sh, let's do it.

> > 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.

I think keeping the whole GRUB in memory for that purpose would be a
major overkill.  I would probably create a file map on the disk (like,
sectors 0-10 of the file are in sectors 1000-1010 of the disk etc) and
leave a simple interrupt handler that would emulate a BIOS disk by using
that map.

But I don't see it as priority.

> > 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.

Floppies are not the same device.  Yes, there is some risk accessing a
CD-ROM while BIOS accesses a hard drive on the same controller.  But I
think GRUB would never do it in parallel.

>  I would prefer ehci driver and floppy driver if someone
> still needs them

USB needs work, that's for sure.

Floppies can be supported via int 13 even if the ATA module is in use.
Or we can use int 40 to be extra safe.

> >  We also
> > need AHCI support.
> >
> Isn't it already the case?

I don't see it.

-- 
Regards,
Pavel Roskin