Re: [RFC] New kernel-message logging API

Rob Landley
2007-09-25T01:46:52Z

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?

Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.