All of lore.kernel.org
 help / color / mirror / Atom feed
From: phcoder <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] badram filtering
Date: Tue, 10 Mar 2009 13:56:51 +0100	[thread overview]
Message-ID: <49B66393.2040301@gmail.com> (raw)
In-Reply-To: <20090227194253.GA31474@thorin>

Very interesting. I have following suggestions:
1) define platform independent way to enumerate memory map. This 
function wouldn't mark types with GRUB_MACHINE_* but with one of the 
following types:
GRUB_MMAP_HOLE - means that at this position there is no RAM at all. 
Should this be iterated at all?
GRUB_MMAP_IO - usable only by I/O drivers
GRUB_MMAP_FREE - usable by ACPI and firmware-unaware OS. But may be 
unusable by grub itself. memory allocator should be used for requesting 
memory in grub
GRUB_MMAP_ACPI - usable by ACPI-aware OS after loading tables
GRUB_MMAP_PLATFORM_FIRST...GRUB_MMAP_PLATFORM_LAST - platform specific 
types which can't be used except by firmware-aware code and OS
2) when badram variable is set corresponding memory chunks should be 
removed from memory manager
3) add a method to specify badram in init.c so that grub2 itself has no 
risk of using any of this memory. I propose to embed initial environment 
in core.img. Then prefix and root can be changed to use this mechanism. 
It would also be able to override this initial environment through 
multiboot command line when grub2 is loaded by multiboot loader


Robert Millan wrote:
> Hi,
> 
> This patch implements badram filtering in GRUB.  It's the same idea as in
> http://rick.vanrein.org/linux/badram/ but applied to GRUB.
> 
> The badram module sits between loaders (or other users like lsmmap) and
> filters the mmap entries, but only when user previously set the "badram"
> variable (whose syntax is the same as the one in badram patch for Linux).
> 
> NOTE this won't affect loadees that get the memory map from BIOS instead
> of from GRUB.  This means it currently works for Multiboot and for the
> new/experimental Linux loader.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko



  reply	other threads:[~2009-03-10 12:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-27 19:42 [PATCH] badram filtering Robert Millan
2009-03-10 12:56 ` phcoder [this message]
2009-03-10 17:46   ` phcoder
2009-03-11 20:37     ` phcoder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49B66393.2040301@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.