Messages in this thread | | | Date | Tue, 31 Mar 2009 08:58:03 -0700 | Subject | Re: [RFC] Add Alternative Log Buffer Support for printk Messages | From | Grant Erickson <> |
| |
On 3/30/09 7:22 PM, Carl-Daniel Hailfinger wrote: > On 21.01.2009 18:39, Grant Erickson wrote: >> This merges support for the previously DENX-only kernel feature of >> specifying an alternative, "external" buffer for kernel printk >> messages and their associated metadata. In addition, this ports >> architecture support for this feature from arch/ppc to arch/powerpc. >> >> When this option is enabled, an architecture- or machine-specific log >> buffer is used for all printk messages. This allows entities such as >> boot loaders (e.g. U-Boot) to place printk-compatible messages into >> this buffer and for the kernel to coalesce them with its normal >> messages. >> > > What is your current status for this patch? I'd like to make sure the > implementation will not be incompatible with the coreboot log buffer.
Carl-Daniel:
Unfortunately, the project with which the patch was associated has since wrapped up and I have not had the cycles in the intervening period to follow-up "mainlining" the patch.
Philosophically, my perspective, based on the ensuing RFC dialog, is that my preferred tack would be something akin to a log buffer driver model. For 99.99% of the cases, the standard would be the generic log buffer driver we all know and use today.
However, under the driver model, also available would be the u-boot read/write log buffer driver, the read-only slurp-up-the-firmware-log-and-append driver proposed by Andrew, whatever David proposes for Sparc, perhaps something slightly different for Coreboot, etc. Some of these may/may not support ALL the options the generic driver supports (e.g. resizing through a kernel parameter).
Compatibility on the back end among all these is a laudable goal; however, given the varying requirements of the embedded space in which these variant drivers are inevitably targeted, it seems unreasonable to expect they'll all converge into a "one true log buffer driver".
So long as the front-end driver API is compatible with the current generic driver, printk, klogd, etc., the kernel configurator is free to select the driver that makes the most sense for his/her board/application/etc.
So, that's as far as I got with the philosophy. My next step would have been creating drivers/log, moving the generic driver pieces there from kernel/printk, establishing a u-boot driver as a representative variant, roll in Andrew's feedback, etc.
Regards,
Grant
| |