Dear Lee Jones,
In message 20121121143928.GA28899@gmail.com you wrote:
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.
It is my opinion that mechanisms as ATAGS or device tree are inappropriate for passing any kind of log data to the kernel.
So far, the established way of passing logging information (like results of Power-On Selft Tests,e tc.) is through a shared log buffer.
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.
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?
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.
Best regards,
Wolfgang Denk