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 ...

+ Reply to Thread
Results 1 to 3 of 3

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

  1. 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.

    Rob
    --
    "One of my most productive days was throwing away 1000 lines of code."
    - Ken Thompson.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. 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.

    cheers, Joe

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

  3. 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?

    Rob
    --
    "One of my most productive days was throwing away 1000 lines of code."
    - Ken Thompson.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread