From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lh62a-0007dS-40 for mharc-grub-devel@gnu.org; Tue, 10 Mar 2009 13:46:56 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lh62X-0007Zb-RD for grub-devel@gnu.org; Tue, 10 Mar 2009 13:46:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lh62W-0007Z8-Eo for grub-devel@gnu.org; Tue, 10 Mar 2009 13:46:52 -0400 Received: from [199.232.76.173] (port=50753 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lh62W-0007Z5-8w for grub-devel@gnu.org; Tue, 10 Mar 2009 13:46:52 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:64259) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lh62V-0003F5-Ox for grub-devel@gnu.org; Tue, 10 Mar 2009 13:46:52 -0400 Received: by fg-out-1718.google.com with SMTP id l27so976199fgb.30 for ; Tue, 10 Mar 2009 10:46:50 -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=mkfIRTKSjWzlVrBiLipz+w+tC80abE2WAiX1qNjrHTg=; b=iUR/9eGkj2jSEdfEQV6zBnODqrOP6USJvLGPekpcNNztktl2NlNSdDQiBBW8Auw2+c bm09SP9cruXRNy/14jEyAPAMIgUzWvaOsUhjwJCdZ+yBmvc/g4OVGe8fODPpHPOarWWu EqIFqZoKgr3+r5/Gw/cvx5VYOXYbfnKksigX4= 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=YBuWs+5lhEfb7qigbLBn2jH9tkBuRgCt/zROAyYYPu8+XN13+9vBsGGlpsAf0dFxLB agn6GK64ee14FUM0t6qIFzYbCbCMOclk90t6xxARw1i2dmuev4n2K0NMUzyPcQwbBv3B ap/3FwIFoib3AKHDKj7fDIzlTgWKw00+jdyHI= Received: by 10.86.53.8 with SMTP id b8mr5231954fga.13.1236707210269; Tue, 10 Mar 2009 10:46:50 -0700 (PDT) Received: from ?192.168.1.2? (32-95.3-85.cust.bluewin.ch [85.3.95.32]) by mx.google.com with ESMTPS id e11sm5297449fga.20.2009.03.10.10.46.49 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Mar 2009 10:46:49 -0700 (PDT) Message-ID: <49B6A789.3080600@gmail.com> Date: Tue, 10 Mar 2009 18:46:49 +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> <49B66393.2040301@gmail.com> In-Reply-To: <49B66393.2040301@gmail.com> 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 17:46:54 -0000 I've looked in depth in memory map and have seen that (1) is already done so except for EFI systems. And except that memory types are defined on per-machine basis. IMO generic memory types should be shared at the output of grub_machine_memory_iterate but it's not critical. I will code a similar function for EFI and adapt multiboot loader for EFI systems phcoder wrote: > 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