[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Two SoC ideas
Re: Two SoC ideas
Sun, 25 Mar 2007 13:35:57 +0800
Why the modaddr can not be accepted by multiboot specification ? By
default, grub loads the multiboot modules right after multiboot kernel.
Some microkernel want to keep the multiboot module images in memory, if
a driver crashed it can be reloaded from the image.
On x86 platform, this scheme will consume much DMA memory. So a command
like modaddr is very useful to save memory in DMA area. I dont know
whether other platforms use Grub, but x86 is the most popular one.
在 2007-03-24六的 23:57 +0100，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
> "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.
> Grub-devel mailing list