From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones Date: Wed, 21 Nov 2012 15:03:32 +0000 Subject: [U-Boot] [PATCH 3/8] boottime: Add core boottime measurement support In-Reply-To: <20121121134424.57C3B2003CF@gemini.denx.de> References: <1353422034-28107-1-git-send-email-lee.jones@linaro.org> <1353422034-28107-4-git-send-email-lee.jones@linaro.org> <20121120182047.A5A1120009C@gemini.denx.de> <20121121095045.GI28265@gmail.com> <20121121134424.57C3B2003CF@gemini.denx.de> Message-ID: <20121121150332.GC28899@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > > 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