On Wed, 23 Dec, at 12:11:56AM, Elliott, Robert (Persistent Memory) wrote: > > I was trying to make it resemble the memmap=size@address > kernel parameter format for creating e820 entries, which > does accept abbreviations in addition to hex values: > memmap=nn[KMG]@ss[KMG] for usable DRAM > memmap=nn[KMG]#ss[KMG] for ACPI data > memmap=nn[KMG]$ss[KMG] for reserved > memmap=nn[KMG]!ss[KMG] for persistent memory > > Mapping the UEFI type to the corresponding @, #, $, or ! was > more than I wanted to tackle, so it's not a drop-in > replacement string. > > memparse() also accepts T, P, and E units; I guess those > need to be added to Documentation/kernel-parameters.txt. I think the value of the "@ address" portion of the string is questionable. > Thanks for the pointer; I wondered if there was a similar > function somewhere. However, that function throws away > precision in favor of printing just 3 significant digits; > I think that's dangerous. Its non-integer output is not > supported by memmap=, and the function appears to use > assembly code to get CPU divide instructions, losing the > ability to use shifts for these power of two divisions. > > Example results... > > efi: mem01:... range=[0x0000000000093000-0x0000000000093fff] (4 KiB @ 588 KiB) > efi: mem01:... range=[0x0000000000093000-0x0000000000093fff] (4.00 KiB @ 588 KiB) SGS > > efi: mem03:... range=[0x0000000000100000-0x00000000013e8fff] (19364 KiB @ 1 MiB) > efi: mem03:... range=[0x0000000000100000-0x00000000013e8fff] (18.9 MiB @ 1.00 MiB) SGS > (example of lost precision: 19364 KiB is really 18.91015625 MiB) > > efi: mem04:... range=[0x00000000013e9000-0x0000000001ffffff] (12380 KiB @ 20388 KiB) > efi: mem04:... range=[0x00000000013e9000-0x0000000001ffffff] (12.0 MiB @ 19.9 MiB) SGS > > efi: mem28:... range=[0x00000000717c2000-0x0000000072acafff] (19492 KiB @ 1859336 KiB) > efi: mem28:... range=[0x00000000717c2000-0x0000000072acafff] (19.0 MiB @ 1.77 GiB) SGS > > efi: mem57:... range=[0x0000000880000000-0x0000000e7fffffff] (24 GiB @ 34 GiB) > efi: mem57:... range=[0x0000000880000000-0x0000000e7fffffff] (24.0 GiB @ 34.0 GiB) SGS Good points! I agree that string_get_size() (unfortunately) doesn't look useful in this scenario. The code in efi_size_format() looks fine. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
