Dear Lee Jones,
In message 20121121174856.GC417@gmail.com you wrote:
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
It is definitely used that way. For example, there are systems that parse the syslog output for specific POST results, and prevent certain functionality to be enabled when the POST detected problems with the hardware, or other conditions that require specific actions.
time statistics in one, easy to access place so that (generally kernel) engineers may make improvements based on the data provided.
And it has to be implemented using a completely new method, because all existing ones are crap or not the "correct way" to do it. We've been there before.
If I print my current bootgraph it's currently 507 lines. This should not go into the kernel log at any level. Albeit almost
"This should not". OK, this is your decision, whatever the reasoning for it may be, and whatever others may think about it.
I accept this, but please also accept that I ask you not to add code that duplicates existing functionality to U-Boot.
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.
Again, this is your opinion. My strong believe is that it is almost always much more advisable to implement such functionality not in the kernel, but in user space. There are certain things that belong to the kernel, but everything else should not be done there. Gathering and processing statistical information, generating charts and the like are nothing I consider typical kernel tasks.
But we're off topic here - this is the U-Boot mailing list, and I'm not in a position to citizise the design of your kernel code.
But as much as you "don't want two different mechanisms for storing bootloader and kernel entries" I don't want that either. And that is the reason to reject these patches, asking for a change of the implementation to use the already existing methods.
Best regards,
Wolfgang Denk