Yes, I intend to extend this functionality into Device Tree. That way it will be architecture and OS independent.
And forcing something upon a mechanism that was designed for a completely different purpose, where you see right from the first glance that it does not math easily?
Not entirely sure what you mean here. This mechanism works perfectly with ATAGs.
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 can also drive a nail in using a microscope as hammer.
Ah good idea. I have to try this. ;)
The advantages should be obvious: we will need no extra kernel modification, we do not depend on ATAGS, and we are automatically architecture-independent.
Wouldn't this clog up the kernel's log buffer? I'm sure no user wants to see reams of otherwise useless logging scrawled throughout their bootlog. We'd also have a write a text parser to obtain the information for processing. It would be easier to either pass in a struct, as we do with the ATAG mechanism, or though Device Tree as previously discussed.
I think these are pretty poor arguments. There are standard methods (like log levels) to provide adequate filtering of which messages are passed on to a user. An there exists a plethora of tools for automatic filtering and post-processing of syslog messages. You will need to write _less_ code than with your homebrew implementation.
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.