Re: [RFC] Add Alternative Log Buffer Support for printk Messages

[Grant Erickson <gerickson@nuovations.com>]

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