If you are not interested in such information, then just use appropriate log levels and filtering.
I think the kernel log is the wrong place for this to go. Although,
OK, this is your opinion, then, and I will respect it.
Thank you, and I yours.
It is my opinion that mechanisms as ATAGS or device tree are inappropriate for passing any kind of log data to the kernel.
I agree with you.
So far, the established way of passing logging information (like results of Power-On Selft Tests,e tc.) is through a shared log buffer.
Also true, but is that data used in this way? Or is it just printed out at boot time? This tool aims to gather all boot time statistics in one, easy to access place so that (generally kernel) engineers may make improvements based on the data provided.
the kernel driver will allow you to print the information in a log format by cat'ing <debugfs>/boottime/bootgraph, it's not really kernel logging information. It's mearly a collection of trace-points containing a timestamp and some means of identification.
I don't see what a kernel driver may be needed for, but for this part of the discussion this is not relevant anyway.
I've already had lots of interest in this from the kernel community, but if it can't make use of the bootloader portion easily, then it just becomes another tracing/bootchart mechanism.
Filling the kernel log with lots of trace-points is definitely wrong.
Again, this is your opinion, and I respect it. On the other hand, what is the kernel log being used for on log level INFO, for example?
If I print my current bootgraph it's currently 507 lines. This should not go into the kernel log at any level. Albeit almost all of them are kernel related entries, I've already mentioned that I don't want two different mechanisms for storing bootloader and kernel entries. It's very rare that you'd even need to print it out, but when you do it's there in debugfs.
So you're suggesting that we create a userland portion of the driver too? I don't think this is acceptable. This tool will be used by kernel engineers, who would be more happy taking the information from debugfs. At least I know I would.
I do not suggest anything like that. I suggest not to write any driver at all, nor any other code. I suggest to use existing tools, as I recommend to reuse existing (standard) methods and protocols instead of inventing new ones.
You're suggesting that we parse the log with a bespoke text parsing tool in order to get the information we need. However, this would a) require us to overwhelm the kernel's log and b) We'd have to maintain a separate script or app that would be capable of the task. I'm just not happy with the implementation.
To have something in the kernel, which does all this automagically would be much simpler for the user. This tool was created to solve a real problem. Kernel engineers do not currently have an easy way to trace booting time from bootloader. This is the solution to that problem.
1. Enable boottime config 2. Enable debugfs config (if it's not already) 3. Mount debugfs (if it's not already) 4. cat /sys/kernel/debug/[summary|bootgraph]
Simples.