> > > show_boot_progress() code? Did you consider using this instead? If > > > so, why did you not use it? > > > > No, I didn't know it existed. Basically I've taken responsibility to > > upstream someone else's driver. It's more of a kernel thing, but it > > This shouldbe considered a design fault. > > Why do you need an extra driver when standard mechanisms exist that > provide exactly the needed funtionality? > > > requires boottime information from u-boot too, as the intention is > > to cover full system booting, rather than the kernel-only tracing > > mechanisms which already exist. > > But we can share a log buffer with Linux, both hence and back, so why > do you not simply use this feature? > > > I've just taken a look at show_boot_process() though. It doesn't > > appear to be suitable for what we require. Each tag needs to be > > individually identifiable, and I'm not sure how you would achieve > > this if we were to call back into a single function which would do > > the tagging. > > Each call takes an argument which is exactly used for such > identification purposes. And you implementation can be mapped to > write syslog entries into a shared (with Linux) log buffer, so no > changes in Linux are needed.
It looked to me as though it took an integer identifier, which isn't going to mean anything to anyone. Unless there is a way to change the semantics of the function so that it would take a string, but then how would it play with the existing show_boot_progress() calls? -- 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
