[gPXE] [PATCH] dmesg command - console memory buffer

[Michael Brown]

On Saturday 03 Jul 2010 21:31:04 M Lowe wrote:
> I don't know if anyone else would find this useful or not. This patch
> adds support to log all console IO to a buffer. The dmesg command can
> then display the buffer utilizing more-style paging or dump it to a
> remote host via TCP.
> 
> I used this to debug my PCI-e InfiniBand sanboot setup. Vintage serial
> ports weren't available on the computer so this was the easiest option.
> (Although trying out QEMU's pci-e pass-through was a close second.)
> 
> The entire code is modularized using gPXE's awesome linker table
> methodology and this patch sets it to disabled in the main config by
> default.

Nice idea.  I'm not sure what the benefit is of dynamically allocating the 
dmesg buffer, though; why not just have a static buffer in the .bss section?

Note that umalloc() is very restrictive in terms of when you can safely call 
it; in particular, you cannot use it if you do not have top-level control of 
the system.  For example, if you have already started a SAN boot and there is 
the chance that e.g. NTLDR may have already read the system memory map, or if 
you are being invoked via the PXE API, then it is not safe to call umalloc().

(There is some code in gPXE that violates this constraint; some of the 
Infiniband devices require very large (>8MB) allocations that cannot be 
satisfied in any other way given the 1MB overall size constraint on gPXE 
imposed by the A20 limitation.  (iPXE no longer has this limitation, but still 
uses the potentially dangerous umalloc()s for the >8MB buffers at present; this 
could change in future.)

> + * Why does the serial driver have it's own INIT level?

This is done so that initialisation-time debug messages may appear via the 
serial console.

Michael