[Top][All Lists]
[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