On Wed, 21 Nov 2012, Wolfgang Denk wrote:
Dear Lee Jones,
In message 20121121150332.GC28899@gmail.com you wrote:
Neither ATAGS not the device tree are intended nor designed for passing logfile information. Yes, you can use them like that, and it will actually work.
ATAGs were exactly designed for this type of thing. To pass small data structures though to the kernel. In our case, our trace-points are held in a small data structure. They're not logs.
You appear to have a specific definition of log data in mind. It must be different to mine.
I would say that a log entry would contain useful descriptive information contained. It is _sometimes_ useful to display a related timestamp too. In our case, the most useful part is the timestamp. I just don't see how riddling the kernel log with timestamps would be useful, or nessersary.
Also, you contradict yourself - here you write "pass small data structures", earlier you wrote about "lots of trace-points", which sounds as if the total amount of data would be not exactly small - actually so big that yu are afraid of annoying users with it.
Right, perhaps I should have been more descriptive. I don't see the bootloader passing lots of these trace points. The current configuration will allow 10; however, the kernel logs one for every cecal. This would quickly fill the kernel log with lots of unwanted bumph. I also would like to store the data for bootloader and kernel in the same manor. Placing the bootloader's trace points in the kernel log, then putting the kernel's ones somewhere else would add unwanted complexity. Especially if you're wanting the user to write an app for parsing. I would prefer it if all of the processing could be done in the kernel and displayed nicely via debugfs.
Anyway. This doesn't take us further.
They're not poor augments if the data stored isn't log messages, which these aren't. If anything I would say that ramming them in as textual kernel messages, then parsing the log text using a userspace tool was an abuse of the system. If we create them as data in the bootloader, then pass them to the kernel as data, then process them as data, _that_ would be the correct mechanism.
Well, I could pooint out here a number of pretty basic design decisions made earlier in a number of pretty important and successful software projects, like the fact that a large number of internet protocols are based on plain text implementations. Or how useful it is if you can just to a post-mortem dump of the log buffer and actually _read_ the entries, without need to special tools.
You can do that in the current implementation though debugfs:
$ cat /sys/kernel/debug/boottime/bootgraph [ 0.023024] calling board_init+0x0/0x0 [ 0.177808] initcall board_init+0x0/0x0 returned 0 after 154 msecs. [ 0.177808] calling main_loop+0x0/0x0 [ 0.179632] initcall main_loop+0x0/0x0 returned 0 after 1 msecs.
It is your suggestion that would require _extra_ bespoke tools for parsing and actually obtaining the information you require. Where as we can just do this:
$ cat /sys/kernel/debug/boottime/summary bootloader: 5484 msecs kernel: 2265 msecs total: 7750 msecs kernel: cpu0 system: 75% idle: 25% iowait: 0% irq: 0% cpu1 system: 2% idle: 97% iowait: 0% irq: 0% bootloader: cpu0 system: 100% idle: 0% iowait: 0% irq: 0%
I think I should stop here, though. It appears it makes little sense trying to discuss alternative approaches when you have already fixed your mind about the one and only "correct" way to do this.
Not at all. I am open to new and different approaches, so long as they are better. I just don't agree that munging a timestamp and id (usually a function name) into a text string and shoving it into the kernel's log buffer is in any way 'better'.
I hope you can at least see my point.