Messages in this thread | | | From | David Laight <> | Subject | RE: [RFC PATCH 1/5] printk: implement pr_cont_t | Date | Thu, 20 Aug 2020 07:44:23 +0000 |
| |
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)
| |