GRUB and modaddr
colyli at gmail.com
Wed Jan 17 17:13:40 CET 2007
Hi, I checked both Grub legacy and Grub2, no modaddr there :-( But
really this feature is necessary. Here is an example:
a kernel is loaded at 0x100000 with length of 0x100000 bytes (a huge
one). and some multiboot modules are loaded by Grub at the end of the
kernel area (this is what Grub does now).
When kernel initiates, especially for the memory management, it has to
build kind of data structure dynamically to management the page frames
for this booting (number of page frames is variable by the size of
Once it needs some where to dynamically memory allocation, it should not
overlap this data structure in where the multiboot modules loaded.
The solution could be:
1, Skip the area of loaded multiboot modules. This solution needs kernel
to be aware of the layout of all the multiboot modules, which needs some
2, Set a address to Grub, tell Grub to load all of the multiboot modules
after this address. So we can make sure kernel's dynamic allocated
memory will not overlap the multiboot modules. once kernel initiated the
memory management stuffs, it can reserve the area of multiboot modules.
The first solution is what I have done in my MLXOS, I really hate it. If
upstream Grub has a modaddr feature, I can live easier.
在 2007-01-17三的 15:39 +0000，Manuel A. Fernandes Montezelo写道：
> 2007/1/17, Christian Helmuth <ch12 at os.inf.tu-dresden.de>:
> > Hi,
> > On Wed, Jan 17, 2007 at 01:41:29PM +0000, Manuel A. Fernandes Montezelo
> > wrote:
> > > Still, aren't there any plans to try to get Fiasco-with-modules
> > > running in vanilla versions of GRUB, or the new GRUB2? It will be
> > > quite useful for people trying to test it, I think.
> > On the other hand, 'modaddr' may be a cool feature for vanilla GRUB,
> > doesn't it?
> I don't know yet why is it necessary, etc -- so I can't say much about
> the usefulness of the feature.
> But my question also included the possibility that you mention, that
> is, if you have plans to contact GRUB devels to integrate that feature
> in the upstream version, or they already rejected it, or what.
> Whatever works so people don't need to use forks of the tools would be
> nice, I think :)
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
More information about the l4-hackers