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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 31 Mar 2009 08:58:03 -0700
From:	Grant Erickson <gerickson@...vations.com>
To:	Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@....net>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Timo Juhani Lindfors <timo.lindfors@....fi>,
	Wolfgang Denk <wd@...x.de>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Add Alternative Log Buffer Support for printk Messages

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/