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

[Wolfgang Denk]

Dear Lee Jones,

In message <20121121101310.GL28265 at gmail.com> you wrote:
>
> > 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?

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

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.

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As far as the laws of mathematics refer to reality, they are not cer-
tain, and as far as they are certain, they do not refer  to  reality.
                                                   -- Albert Einstein