From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LqsNq-0002m4-Gq for mharc-grub-devel@gnu.org; Mon, 06 Apr 2009 13:13:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqsNo-0002kb-KJ for grub-devel@gnu.org; Mon, 06 Apr 2009 13:13:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqsNm-0002j2-QV for grub-devel@gnu.org; Mon, 06 Apr 2009 13:13:15 -0400 Received: from [199.232.76.173] (port=44471 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqsNm-0002iy-N2 for grub-devel@gnu.org; Mon, 06 Apr 2009 13:13:14 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:17137) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LqsNm-00023z-6L for grub-devel@gnu.org; Mon, 06 Apr 2009 13:13:14 -0400 Received: by fg-out-1718.google.com with SMTP id l27so256346fgb.7 for ; Mon, 06 Apr 2009 10:13:13 -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=BPucpWYiyY4Tj/m6y1Lpl2tD8r1FMAjfwk5IMMbuJPA=; b=XBEPXSHFTYzH2TROqqajG7DOQB6IYJNg2yXhqz+bRN99ZiUTE7dM1K1NvrGf4EKFej eO47vwWZA/7B4G+LCtYHbKchnHEHVeep0xPVDUuZ/2WuG5KC3QQsr2b6P5E8WSGO9jHC wriof2wKkr3O5y5geSJD+OmjtMEGXQcXxVklg= 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=RQw6PbiIjRYzG1vuA8dqGXVGB7Jze2WadlRadsAgwtn842tATHewT0eWh0lyr7N469 dBxkQIsxzkSGhrxqbb0ppj73zLBlrwOZDdWj2FG040P2hOeO9gJQULfCCYDzWPmgMB3n p8zFD74ejN+Qe8/nL8aYLhoJ/um6IfMGM3vHI= Received: by 10.86.36.17 with SMTP id j17mr2056491fgj.1.1239037993096; Mon, 06 Apr 2009 10:13:13 -0700 (PDT) Received: from ?192.168.1.2? (153-81.3-85.cust.bluewin.ch [85.3.81.153]) by mx.google.com with ESMTPS id 4sm12467832fgg.0.2009.04.06.10.13.12 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Apr 2009 10:13:12 -0700 (PDT) Message-ID: <49DA382A.3080608@gmail.com> Date: Mon, 06 Apr 2009 19:13:14 +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> <49D8A8E6.4040300@gmail.com> In-Reply-To: <49D8A8E6.4040300@gmail.com> 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: Mon, 06 Apr 2009 17:13:17 -0000 phcoder wrote: > 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") IMO this code needs to integrate with normal mm. Also mm can have a machine-dependent backend to allocate more pages or to do claimmap on pages normally not supposed to be in mm > 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