grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two SoC ideas


From: coly
Subject: Re: Two SoC ideas
Date: Sun, 25 Mar 2007 13:35:57 +0800

Okuji:

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.

Best regards.

Coly

在 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 
> 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
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]