Re: Some ideas about new features of grub

[Bean]

Hi,

>> 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.
>
> I don't mind LUA being supported, but I think it's unnecessarily big
> for the task GRUB is usually going to perform (the canonical example
> of that is in the default grub.cfg) in the majority of cases.  I'd
> like to see *that* use case made more robust instead of switching to
> something else to obtain a flexibility we don't currently need.

With LUA, we can have a more user friendly interface. I like way rEFIt
works, it doesn't require configuration. At runtime, it detects os and
shows an icon for each of them. We can achieve similar goal using lua.
Of course, advanced user can write the menu manually, but for most
user, a smart auto-generated menu may be more appealing.

>
>> 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 don't mind write filesystem support as long as its infrastructure is
> completely isolated from the kernel.  That said, I think Marco objected
> to this before, so you'll have to talk with him about this.
>

A while ago, grub4dos add write support for fs. Actually, it's quite
limited and can only overwrite existing data. But already, people has
used it to implement something like 0PE (zero sized PE), which
generate the PE image on the fly. It's amazing what you can do which
such function. And I think it shouldn't cause security issue, as the
write driver needs to be loaded explicitly.

>> 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.
>
> Sounds like a killer feature, but would this actually work?  Once whatever
> we're loading stops using the BIOS, it won't see the virtual drive anymore.

Yes, it's used for BIOS based os like MS-DOS/FreeDOS. There is still
some usage for them, for example, many low level maintainer tools
still runs in dos.

-- 
Bean