> > 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. -- 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
