From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LqRnO-0000dM-Ro for mharc-grub-devel@gnu.org; Sun, 05 Apr 2009 08:49:54 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqRnN-0000c0-F7 for grub-devel@gnu.org; Sun, 05 Apr 2009 08:49:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqRnI-0000XX-5a for grub-devel@gnu.org; Sun, 05 Apr 2009 08:49:52 -0400 Received: from [199.232.76.173] (port=56942 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqRnH-0000XO-Ql for grub-devel@gnu.org; Sun, 05 Apr 2009 08:49:47 -0400 Received: from mail-fx0-f166.google.com ([209.85.220.166]:61591) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LqRnH-0007aA-7Z for grub-devel@gnu.org; Sun, 05 Apr 2009 08:49:47 -0400 Received: by fxm10 with SMTP id 10so1663907fxm.42 for ; Sun, 05 Apr 2009 05:49:46 -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=KRQnHcF+r9W/3ZHixEsBmfxZme4aBZGEytlfJfI93Cc=; b=wZLfD8pBscnHIxWSAfQJ4lq18pO5SiWBrH2u34PxA4tD1kpjiZto+AzBunoOCObRuJ rPfGfswPEWp6S5zXB5qgD+3SyW35xEZpoycdLAlIejEZMhAPmtsaVmJm6N2FkH/Jyldg 1mr3vPkrkkBI1IcxHhv3NqPoSRaYK8cVuqFJo= 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=xAD+9uLDOgKafn6tiZioe04qZHGuqKVJUDqC+WrEJnWw8usAffYJu3PRqGVaHTaNoc LB9xLHtOo8bb/qO+MpVENlUY29k4NEIpYKf1kGJ2+jCt6fvIuWAlXOKdBOSXr5P/RI9R LV/xeUDK8DdCRQFtMdpiqDMzBbBMMFrSoKi/U= Received: by 10.86.82.16 with SMTP id f16mr2297557fgb.32.1238935786185; Sun, 05 Apr 2009 05:49:46 -0700 (PDT) Received: from ?192.168.1.25? (240-88.62-81.cust.bluewin.ch [81.62.88.240]) by mx.google.com with ESMTPS id d4sm5865972fga.18.2009.04.05.05.49.45 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Apr 2009 05:49:45 -0700 (PDT) Message-ID: <49D8A8E6.4040300@gmail.com> Date: Sun, 05 Apr 2009 14:49:42 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <49D8A2E4.3030908@nic.fi> In-Reply-To: <49D8A2E4.3030908@nic.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: memory allocator enhancements... 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: Sun, 05 Apr 2009 12:49:53 -0000 Hello, one additional consideration is to let grub2 stay in memory even after OS loads. This way it would be possibly to expose any file/partition accessible through grub2 system as a virtual int13h disk. For this to be a it's very desirable to put all modules that may need to stay, the kernel and corresponding memory at the end of lowmem/uppermem. For OS loading memory at fixed address may be allocated by functions like grub_claimmap on ieee1275 (I have some code in this direction in my patch "multiboot on EFI") Another idea is to allocate invalidatable blocks like disk cache in the middle of the memory. It would decrease the memory fragmentation and if it conflicts with any other allocation it can be easily invalidated Vesa Jääskeläinen wrote: > - Seems to be a bit tricky to patch relocation info properly (at least > this is what I was last debugging). Ideas are welcome. Perhaps my code > was not just modified properly... In my efiemu patch I needed to do some similar things (virtual addressing code vs physical addressing code). You may look at my efiemu patch > > 2. Allocate memory for BIOS extensions in order to support BIOS drive > mapping and El Torito or what ever someone needs. > - Probably need to make hole to memory map that is passed to OS so > allocated memory needs to be at end of lowmem so no holes within low > memory are present I propose to integrate this with grub_machine_mmap_iterate. It would be like grub_mmap_iterate - similar to grub_machine_mmap_iterate but with holes created by grub itself grub_mmap_register (start,length, type) - create a memory block of type TYPE. This way all loaders will pass "perforated" map to their kernels. As for kernels using BIOS I would code int15 handler. > - Perhaps this should be only done at last step of boot process. Eg > allocate first memory to high mem and then when boot decision has been > made, then allocate to low mem and make necessary hooks > The patch to do this "preboot hooks" is pending since september > Are there any other needs? For xnu resume to work fine I need to allocate a huge chunk of memory for hibernate image (whole memory minus few MB). It can be anywhere but must be contiguous. > > So what does people feel about these changes. I am afraid if too much > freedom is given it will make it complex... > > Thanks, > Vesa Jääskeläinen > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko