Hi Daniel,
On 7/14/23 02:38, Daniel Kiper wrote:
> On Tue, Jul 11, 2023 at 09:37:15PM +0800, Cyan Yang via Grub-devel wrote:
>
> You are mixing enum and int types. The function should return 0 here.
>
Yes, the hook function should return zero instead of enum vaule
GRUB_ERR_NONE.
> Anyway, I think it would be nice if you could upstream this module.
> Potentially other people may find it useful.
>
Thanks for the suggestion, and yes I was planning to upstream this
module. However, a serious issue have been discovered during the initial
test, made me concerning that this way of presenting the amount of
physical memory should not be considered as the primary way:
When running on a VM it did not report the real amount of system memory.
A few hundred KiB of memory was left undetected, probably reserved by
firmware or hardware.
Here's an example, on a Virtualbox VM:
grub> phymem
The total system memory is 8191 MiB (8589539328 bytes).
while allocated RAM for the VM is 8192MiB (8589934592 Bytes).
Users usually expect the real amount, which should be a multiple of e.g.
2MiB or even bigger. My code[1] is currently rounding the result to the
closest multiple of 2MiB or 128MiB, which depends on platform. The
number is totally an assumption, and there's a chance that some systems
can reserve more than that.
So basically there are two options:
1. We detect the amount of system memory by traversing the GRUB memory
map, return it as is, do not process the result. Downside of this is,
that users who write scripts should pay attention to the possible
"cutout", to avoid using a multiple of 1MiB while doing comparisons:
# This should be avoided if we choose the first option
if [ $total_mem -lt 8192 ] ; then
2. Provide a more accurate way of detecting the amount of physical
memory. Downside of this is there will be more code to write, and more
lot more work to do, as the detection logic probably is platform dependent.
Just add an option to consider "reserved" memory as available. User's choice. Fire you it's a single if.