From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lh1Vy-0007Yk-SQ for mharc-grub-devel@gnu.org; Tue, 10 Mar 2009 08:56:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lh1Vw-0007YV-Be for grub-devel@gnu.org; Tue, 10 Mar 2009 08:56:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lh1Vu-0007Y8-I6 for grub-devel@gnu.org; Tue, 10 Mar 2009 08:56:55 -0400 Received: from [199.232.76.173] (port=50098 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lh1Vu-0007Y5-Cy for grub-devel@gnu.org; Tue, 10 Mar 2009 08:56:54 -0400 Received: from mail-ew0-f179.google.com ([209.85.219.179]:44914) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lh1Vt-0002Uh-Oc for grub-devel@gnu.org; Tue, 10 Mar 2009 08:56:54 -0400 Received: by ewy27 with SMTP id 27so1452109ewy.42 for ; Tue, 10 Mar 2009 05:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=D+9qiwS4GIWNKDGszvUqUR1RwuJ+UvsYRTkcFg4pZS0=; b=VrbE8f8DYwnZCJ0xJJD+Uo03A/nPLV8HMZz/YQcFPW7jTg+INTwMZBRhbCgIiAVexG m/d5gyEKHpNu9wtNuYUFh812JHxOtuD8vJbTBKR0Tjce2qHkg/fbRrpF1MVogapESr3C JkHrNa11+fF4WDF9iic7nFbZRFESlCHDJvdfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=uXS05ml68Mmqg3QlfilJ/1vk6rbteqh5zs33+Z3Kk0vSBrcfJVJtVPVOfRdYEM/OAI jfnJfmaERia6KpHUPIJkq4cI2CGHDqmJuMux9p3Vyaw1WjL356mBbonQQ8mNa+gtT9JT 3aPZ1cO7GXwBBcXSZ0KzxNzPCDTOZn+jXEUak= Received: by 10.216.18.212 with SMTP id l62mr2677034wel.76.1236689812650; Tue, 10 Mar 2009 05:56:52 -0700 (PDT) Received: from ?82.130.79.8? (ifw-public-dock-8-dhcp.ethz.ch [82.130.79.8]) by mx.google.com with ESMTPS id t12sm12863149gvd.20.2009.03.10.05.56.51 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Mar 2009 05:56:52 -0700 (PDT) Message-ID: <49B66393.2040301@gmail.com> Date: Tue, 10 Mar 2009 13:56:51 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <20090227194253.GA31474@thorin> In-Reply-To: <20090227194253.GA31474@thorin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] badram filtering X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 12:56:56 -0000 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