On 3 September 2014 15:24, Laszlo Ersek <lersek@xxxxxxxxxx> wrote: > On 09/03/14 15:01, Ard Biesheuvel wrote: >> On 3 September 2014 13:32, Laszlo Ersek <lersek@xxxxxxxxxx> wrote: >>> changes in v2: >>> - explain with examples how the log's appearance changes, in patches 3-5 >>> [Ingo] >>> >>> v1 blurb: >>> >>>> It's a pain to analyze EFI memmap logs while debugging, especially to >>>> verify the memory types (an enum) and the memory attributes (a >>>> bitmap). This series renders those columns human-readable, and unifies >>>> their formatting between x86, ia64 and arm64. >>> >> >> Tested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> >> (on arm64 only) >> >> +1 for aligning between architectures >> +1 for cleaning up the output to make it more readable >> >> The only thing I am not entirely convinced about is printing all those >> memory attributes: is it really so interesting to know that region X >> /can/ be configured as writeback, write through, write combining etc >> etc, as most regions seem to support most attributes, yet it tells you >> nothing about what the kernel ends up doing with that information. In >> the arm64 case, for instance, all MEMORY_WB ranges are mapped >> writeback cached, and everything else is mapped uncached. > > You don't need these attributes spelled out when you're not debugging. > In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64), > or don't pass uefi_debug=1 (on arm64). > > When you're debugging however, you need every bit of info you can get. > For example, assume a tricky bug in exactly that part of the arm64 code > that you just described above. You'll be flip-flopping between the > kernel source and the original, pristine memory map dump. It's much > easier to ignore a few words / columns in the log (even: cut it out with > a script or interactively) than to read bitmaps in hex (or to decode > them in a script). I know because I grew to hate these hex-encoded > attributes and dec-encoded enum constants when I was developing S3 for > OVMF, and fighting the memmap. > > A good analogue is ACPI debugging in the kernel. The ACPI subsystem > comes with a very elaborate heap of switches, facility bitmaps, log > levels, and so on. The end result is that it is faster to add printks to > your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn > to use the acpi debug flags. (And I did the former when I was recently > fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.) > > So yes, I think that this detailed format is preferable. > OK, you've convinced me :-) Acked-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cheers, Ard. -- 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
