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

[Lee Jones]

> > > I expolained it in my reply to your cover letter, i.e. in the message
> > > immediately preceeding the one you replied to here.
> > 
> > So you're telling me off for sending a patch which doesn't agree with 
> > something you've said, despite you saying it _after_ I sent the patch?
> > 
> > Sounds sensible. :)
> 
> Arghh... you don't _want_ to understand, right?
> 
> I was referring to my reply to your cover letter (patch 0/8) within
> this very patch series.  It makes little sense to repeat what I've
> already told you just one or two messages before, or does it?

I think this is meerly a communication issue. I took "I implicitly 
mentioned this before, here it comes clear again", to mean "I've
told you already, why aren't you listening to me".

> > > like the Linux log buffer for this purpose. As explained, this has
> > > the added benefit that you don't need to change any Linux code. And
> > > you can build on the (also existing) show_boot_progress() support in
> > > U-Boot, so the extesions should actually be really small and pretty
> > > clear.
> > 
> > When you say log buffer, do you mean __log_buf? Doesn't this contain
> > logs used for dmesg; thus won't all this crud end up in a user's
> > dmesg kernel log? Unless there is another log which is used only
> > for the kernel.
> 
> Yes, I do mean __log_buf resp. the syslog services.
> 
> Yes, this will end up in the log buffer than can be displayed with
> dmesg.
> 
> If you consider this information "crud", then consider to disable the
> feature.

It's only "curd" to the user typing `dmesg`. If we're trying to
measure whole system boot-up time, it's useful information.

> But then, guess why highres timestamps have been added to the kenrel
> logs?  For people not interested in such informtion this is eventually
> "crud", but for others it appears important enough that it got added
> to Linux mainline.
> 
> 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,
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.

Filling the kernel log with lots of trace-points is definitely wrong.

> > Also, wouldn't I then have to write a text parser to process this
> > information? Sounds horrendous. Hopefully, I have missed something
> > and it's actually easier than what I've mentioned.
> 
> Guess how many tools are out there that already deal with filtering
> and post-processing of kernel log messages?  A google search for
> "syslog filter" returns millions of hits...

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.

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