From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lnh65-0001pU-3M for mharc-grub-devel@gnu.org; Sat, 28 Mar 2009 18:33:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lnh63-0001ox-65 for grub-devel@gnu.org; Sat, 28 Mar 2009 18:33:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lnh62-0001oX-Cf for grub-devel@gnu.org; Sat, 28 Mar 2009 18:33:46 -0400 Received: from [199.232.76.173] (port=53683 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lnh62-0001oU-8k for grub-devel@gnu.org; Sat, 28 Mar 2009 18:33:46 -0400 Received: from fg-out-1718.google.com ([72.14.220.159]:13715) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lnh61-0003Tf-R1 for grub-devel@gnu.org; Sat, 28 Mar 2009 18:33:46 -0400 Received: by fg-out-1718.google.com with SMTP id 19so518627fgg.7 for ; Sat, 28 Mar 2009 15:33:44 -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=99SSzilemPIRFdSxutC8xU4ocY+AJKz+B7/vh2YsNz0=; b=UlpKSyONCxF6Tep5OTLg+v15wu5+vq3PXVZ5FegsoOszZ/+/FtZ0rxcONjGjNno5A6 Cbax/6XXUCXpGcfHkzimPWiMz/w0tEKbBWB0FCsImP4h4kClZkdXTJNp/u20yNWbsFjq O9hHb2ukBPI6OxgBYjGZhUynWxWovPPJUsMwU= 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=Vz786ctKCEOHUKTaoqQSDf1CUBQB+LZYzhDzVzjuRsr74VTmsE39RxtYaMdh+IhlYh SVZXXm62+7kgQISFX3HJhiKahmQcY19v7ccQrTTh/k7ShHswGPFGyeRB/laoGDzbT9AE xoS5EXnxgIU86oRR/woHhMLrQTlZru3RfBbsE= Received: by 10.86.61.13 with SMTP id j13mr1454315fga.65.1238279624088; Sat, 28 Mar 2009 15:33:44 -0700 (PDT) Received: from ?192.168.1.25? (31-75.1-85.cust.bluewin.ch [85.1.75.31]) by mx.google.com with ESMTPS id 4sm2012464fge.3.2009.03.28.15.33.43 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Mar 2009 15:33:43 -0700 (PDT) Message-ID: <49CEA5CC.1000301@gmail.com> Date: Sat, 28 Mar 2009 23:33:48 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <49C780C3.4010403@gmail.com> <20090328131306.GB8493@thorin> In-Reply-To: <20090328131306.GB8493@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: multiboot on EFI 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: Sat, 28 Mar 2009 22:33:47 -0000 Robert Millan wrote: > Would it be hard to split the patch and make it more granular? I see it > implements base mmap / lsmmap support on efi, then ports the *BSD loaders > and the Multiboot loader too, and the uppermem facility. The only reason why it's not splitted is that it's totally "preview". When it'll be more ready I'll split it > If everybody's fine with it, I'd like to suggest adding stuff to pkglib_MODULES > in the same place as its corresponding variables. I've done this already a few > times, and I think it makes the build system a bit more maintainable. What do > you all think about this? I also agree with this but I temporarily kept this in architecture-specific file because of some minor problems with multiboot2. I'll fix this too > >> diff --git a/include/grub/i386/pc/memory.h b/include/grub/i386/pc/memory.h >> index 08e92a9..e69ff77 100644 >> --- a/include/grub/i386/pc/memory.h >> +++ b/include/grub/i386/pc/memory.h >> @@ -92,6 +92,8 @@ struct grub_machine_mmap_entry >> grub_uint64_t len; >> #define GRUB_MACHINE_MEMORY_AVAILABLE 1 >> #define GRUB_MACHINE_MEMORY_RESERVED 2 >> +#define GRUB_MACHINE_MEMORY_ACPI 3 >> +#define GRUB_MACHINE_MEMORY_NVS 4 >> grub_uint32_t type; >> } __attribute__((packed)); > > Do we need specific knowledge of these two on i386-pc ? > This one is because some loaders just copy e820 map types and I don't want to modify what OS gets on i386-pc >> /* The minimum and maximum heap size for GRUB itself. */ >> #define MIN_HEAP_SIZE 0x100000 >> -#define MAX_HEAP_SIZE (16 * 0x100000) >> +#define MAX_HEAP_SIZE (1600 * 0x100000) > > Is 1600 MB what we want, or to remove the limit? > I would suggest to remove the limit altogether >> + /* Bubble-sort the memory map */ >> + while (done) >> + { >> + done = 0; >> + for (i = 0; i < count - 1; i++) >> + if (regions[i].start > regions[i + 1].start) >> + { >> + done = 1; >> + t = regions[i]; >> + regions[i] = regions[i + 1]; >> + regions[i + 1] = t; >> + } >> + } > > Do we need the memory map to be sorted? AFAIK loadees can cope with unsorted > maps fine; is there an exception? > I prefer to sort. Even as just a precaution. Actually even sorted EFI map may break a lot of OS because it usually has more entries (the runtime code isn't guaranteed to be contiguous and if it isn't it results in mmap having a lot of entries) and sometimes the first N kilobytes are defined as unusable (it's the case with qemu-tianocore) which under current definition means that low_memory=0 >> +#ifdef GRUB_MACHINE_PCBIOS >> + grub_stop_floppy (); >> +#endif > > grub_stop_floppy() doesn't do any BIOS-specific stuff. Wouldn't __i386__ > be more appropiate? > I've already moved it to machine_fini just because my computer died I couldn't send the new patch -- Regards Vladimir 'phcoder' Serbinenko