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

[Rusty Russell <rusty@rustcorp.com.au>]

Laura Abbott <labbott@redhat.com> writes:
> On 12/11/2015 01:39 AM, Rusty Russell wrote:
>> Laura Abbott <labbott@fedoraproject.org> 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@fedoraproject.org>
>>> ---
>>> 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
console.

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;
 }

Confused,
Rusty.