Re: [RFC] New kernel-message logging API - Kernel

This is a discussion on Re: [RFC] New kernel-message logging API - Kernel ; On Monday 24 September 2007 10:19:16 am Joe Perches wrote:
> On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote:
> > Together with the idea of not allowing multiple lines in the kprint_xxx
> > functions, that would go ...

Re: [RFC] New kernel-message logging API

On Monday 24 September 2007 10:19:16 am Joe Perches wrote:
> On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote:
> > Together with the idea of not allowing multiple lines in the kprint_xxx
> > functions, that would go with our approach having message numbers to
> > identify a message.
>
> How does this equate/give message numbers?

I actively want to avoid giving message numbers. My interest is in
selectively removing messages from the kernel to shrink the binary size (and
NOT make it up in either a larger userspace utility to translate them, or
else magic proprietary numbers you can only diagnose if you pay my support
staff).
> An added pass between gcc preprocessor and compiler could compact
> or compress the format string without modifying the conversion
> specifications so __attribute__ ((format (printf)) would still work.

This does not address my problem. Spitting out a proprietary hash code
instead of a human readable message is not a solution for my use case.

Re: [RFC] New kernel-message logging API

On Mon, 2007-09-24 at 18:51 -0500, Rob Landley wrote:
> > An added pass between gcc preprocessor and compiler could compact
> > or compress the format string without modifying the conversion
> > specifications so __attribute__ ((format (printf)) would still work.
> This does not address my problem. Spitting out a proprietary hash code
> instead of a human readable message is not a solution for my use case.

What is your problem Rob?

I think message numbers are difficult to produce from format strings.
I think kernel version/file/func/line is enough to identify messages
for normal use but not too useful for embedded.

I think losslessly compressing, not hashing, the format string
would be useful. The format string would be expanded by printk.
The kernel size would be smaller and more easily fit in minimal RAM.
Losslessly compressing the format strings probably won't reduce
flash image size.

Re: [RFC] New kernel-message logging API

On Monday 24 September 2007 7:10:32 pm Joe Perches wrote:
> On Mon, 2007-09-24 at 18:51 -0500, Rob Landley wrote:
> > > An added pass between gcc preprocessor and compiler could compact
> > > or compress the format string without modifying the conversion
> > > specifications so __attribute__ ((format (printf)) would still work.
> >
> > This does not address my problem. Spitting out a proprietary hash code
> > instead of a human readable message is not a solution for my use case.
>
> What is your problem Rob?

The single largest space savings in the existing -tiny patches comes from
removing printk() calls and strings. I would like to be able to selectively
do this based on severity level, which is information most existing printk()
calls already have. I proposed a minimal change to how printk() works,
allowing the compiler to remove unused code that wouldn't be below the
displayed level of printk() anyway in the deployed product so wouldn't
actually lose any output.

The kernel image is usually already compressed in flash and decompressed to
dram during boot. (Not always, sometimes it's run directly out of flash, but
there's often a speed penalty for doing this, you have to set it up
specially, and dram is cheaper than flash anyway.) This means recompressing
it doesn't help save flash.

If you want to save dram, have printk and associated strings be a function in
a module that's demand loaded and unloaded again after each call. Then you
can foist compression off on userspace, and we're already used to modules
having to match a given kernel version exactly. Why come up with new
infrastructure?