> > > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
