[U-Boot] [PATCH 5/8] arm: Add boottime support for the ARM architecture

[Lee Jones]

> > > 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.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog