File was empty. Sorry
phcoder wrote:
> For those interested in testing: here is a rediff and some updates. Soon 
> I'll split it into components
> phcoder wrote:
>> 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