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. Thanks, Laszlo -- 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
