Re: [PATCH] decouple mmap parsing by using grub_available_iterate()

[Robert Millan <rmh@aybabtu.com>]

On Mon, Aug 11, 2008 at 11:24:18PM +0200, Robert Millan wrote:
> On Mon, Aug 11, 2008 at 06:39:17PM +0300, Vesa Jääskeläinen wrote:
> > Robert Millan wrote:
> > >Hi,
> > >
> > >This patch decouples memory map parsing into a separate 
> > >grub_available_iterate()
> > >function, for i386-pc and i386-coreboot.  It is mostly intended as a 
> > >cleanup.
> > >Makes the code more modular so that, for example, the multiboot loader can
> > >construct a memory map without having specific knowledge of the platform,
> > >allows to recombine various init.c & mmap.c in different ways, etc.
> > 
> > Why not use grub_mmap prefix ?
> 
> You mean like grub_mmap_iterate ?  Seems fine (since the change is trivial,
> I'll skip sending a new patch).

Now that I think, grub_mmap_iterate() would be misleading, as we're only
iterating through the parts of mmap that are marked as available, not through
the whole thing.  How about grub_mmap_available_iterate?

But this reminds me;  with this interface, it's not possible to gather
information about regions other than the ones that are marked as available.
However, AFAICS, there's no purpose for marking a region as reserved, since
the OS is only going to use regions marked as available anyway.

Therefore, if we implement support for Multiboot mmaps in our loader (as
defined in the spec), we wouldn't be able to include non-available regions in
our map.

Does anyone see a problem in this?  If so, then I think we'd need a function
that can for example handle a third argument, for example `type', for this
purpose.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."