[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Two SoC ideas
Yoshinori K. Okuji
Re: Two SoC ideas
Sat, 24 Mar 2007 23:57:44 +0100
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
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
> 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.