lkml.org 
[lkml]   [2020]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [RFC PATCH 1/5] printk: implement pr_cont_t
    Date
    From: Joe Perches
    > Sent: 20 August 2020 01:34
    >
    > On Thu, 2020-08-20 at 01:32 +0206, John Ogness wrote:
    > > Implement a new buffering mechanism for pr_cont messages.
    > >
    > > Old mechanism syntax:
    > >
    > > printk(KERN_INFO "text");
    > > printk(KERN_CONT " continued");
    > > printk(KERN_CONT "\n");
    > >
    > > New mechanism syntax:
    > >
    > > pr_cont_t c;
    > >
    > > pr_cont_begin(&c, KERN_INFO "text");
    >
    > bikeshed:
    >
    > I suggest:
    >
    > printk_begin(&printk_context, fmt, ...)
    > printk_continue(&printk_context, fmt, ...) (maybe printk_next())
    > printk_end(&printk_context, fmt, ...)

    I see some very long source lines looming ...

    Blue bikeshed:

    You'd probably want printk_end(&ctx, NULL) to work.
    Although the example doesn't show where the '\n' comes from.
    Although I guess it is now inferred and actually deleted
    from 'normal' printk() call.

    I've no idea how you'd 'size' the number of buffers.
    You could use kmalloc(), perhaps falling back on a local buffer.
    While might lead to:
    pr_init(&ctx, level, GFP_KERNEL);
    pr_cont(&ctx, fmt, ...);
    pr_flush(&ctx);

    David

    -
    Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
    Registration No: 1397386 (Wales)

    \
     
     \ /
      Last update: 2020-08-20 09:46    [W:3.313 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site