Dear Lee Jones,
In message 20121122101433.GA4328@gmail.com you wrote:
Let's try to move this forward.
Actually you don't. You insist on not changing anything on your side, and ask others to adapt to it.
Okay, to summarise so far:
- Bootloader and kernel mechanisms should be the same
So putting bootloader tracepoints in the bootlog and the kernel's in an internal data structure is not acceptable, as it would add too much extra overhead to link them together and parse.
OK. But this appears a new requirement - your original implementation did not bother about this, using ATAGs here and somethign else there...
- The kernel bootlog is not the correct place for tracepoints
If we were to adhere to point No1 and bootloader & kernel entries would be placed into the bootlog; no self respecting kernel engineer/maintainer will allow 100's of spurious tracepoint entries in the kernel log, regardless of log level.
I wonder about the self-assuredness you speak for all of them. Has this been dicussed in full context before?
Actually, putting it in DT has lots of advantages. 1) DT works cross-architecture and cross-platform, so your architecture independent box is inherently ticked 2) DT already carries non-hardware specific information such as the kernel cmdline. I don't see how adding <10 (but would more likely to be 2-3) tracepoint entries would completely break convention. We can either get the kernel driver to scrub the entries if you'd be that offended by keeping them in.
Hm... in accordance to No. 1 above your kernel code will add new entries to the device tree while the kernel is booting? So instead of "adding <10" it now will be adding "100's of spurious tracepoint entries" to the DT?
Are you sure this is a good idea? [Not considering if it's actually possible.]
But then, if you drop item 1, then what's wrong with "<10 (but would more likely to be 2-3)" additional log messages?
Best regards,
Wolfgang Denk