Re: [RFC][PATCH] module: Limit line length of module prints

From: Rusty Russell
Date: Sun Dec 13 2015 - 22:25:33 EST

Laura Abbott <labbott@xxxxxxxxxx> writes:
> On 12/11/2015 01:39 AM, Rusty Russell wrote:
>> Laura Abbott <labbott@xxxxxxxxxxxxxxxxx> writes:
>>> print_modules currently uses pr_cont to print all module information.
>>> This has the side effect of printing lots of modules on one very long
>>> line. This makes copy/pasting oopses more effort if manual wrapping is
>>> required. Place a reasonable limit (80 chars) on the number of modules
>>> on each line.
>>> Signed-off-by: Laura Abbott <labbott@xxxxxxxxxxxxxxxxx>
>>> ---
>>> Does this bother anyone else or am I the only one who hates dealing
>>> with the long lines of "Modules linked in"?
>> Never bothered me, but I'm a bit odd :) I worry more about the effect
>> on machine parsing.
> Yes, that was a concern I had as well, but the module list seems to get
> wrapped eventually (although at a much longer length) so it seems like
> if machine parsing can handle one wrap it can handle multiple wraps.

Does it? I find that code very hard to parse, but seems like something
happens at 1024 chars.

But my testing here doesn't show any such break in dmesg, nor on serial

diff --git a/kernel/module.c b/kernel/module.c
index 912e891e0e2f..f882d9d99844 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3925,6 +3925,12 @@ static const struct file_operations proc_modules_operations = {

static int __init proc_modules_init(void)
+ int x;
+ printk("Test of long line:");
+ for (x = 0; x < 1024; x++)
+ pr_cont("%c%c", (x % 26) + 'A', (x % 26) + 'A');
+ pr_cont("\n");
proc_create("modules", 0, NULL, &proc_modules_operations);
return 0;

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at