Re: Two SoC ideas

[Yoshinori K. Okuji]

On Friday 23 March 2007 16:46, Wei Shen wrote:
> 1) Simple file editing
>
> I think it is useful to add file edit function to Grub. Thus, if a config
> file which is required to boot the OS successfully is mistakenly written,
> we can still correct it in Grub and need not to reboot from the floppy or
> cdrom just for the correcting.
> I know it would greately increase the complexity of Grub to support a
> writable file system. However, if file writing does not change the block
> number of a file, things are much simpler. Since most config files are
> small (occupying only one block), I think the solution will work.

If you don't change the file size, it would work mostly. And this is exactly 
how "savedefault" works in GRUB Legacy.

But I am a bit pessimistic with this approach. For example, ZFS computes a 
checksum for every block, and embeds the information into a parent node. This 
means that, when GRUB modifies any bit of data, GRUB must recompute a 
checksum and write it to somewhere appropriate. Otherwise, a filesystem would 
be corrupted.

Theoretically speaking, nothing prevents GRUB from doing that. But this 
illustrates that GRUB must deal with writing very carefully, and the 
semantics depends on each filesystem. I do not know if a kind of volume 
manager, such as LVM, performs this kind of check, but if it does, we need to 
support it as well.

So this work is not as trivial as at the first glance, although we need it for 
"savedefault" definitely.

> 2) *addr* option for module command
>
> Add nn option: "*addr* = *value*" to the module command. If the
> *addr*option is specified, Grub will load the module to address
> *value* instead of the default address.

We discussed this in bug-grub a long time ago. If you are interested, please 
look at the archive, and search by "modaddr".

In summary, I do not like this, because it is a non-standard extension to 
Multiboot Specification. If you depend on this feature, your users would be 
restricted to using GRUB, and they would not be able to use any other 
Multiboot-compliant boot loaders. This is against the spirit of the Multiboot 
Specification, which addresses portability problems in boot protocols.

So this must be accomplished as a part of Multiboot Specification. Otherwise, 
I do not want to accept it.

Thanks,
Okuji