Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1289058 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [RFC][PATCH] module: Limit line length of module prints Laura Abbott <labbott@fedoraproject.org> - 2015-12-11 03:00 +0100
    Re: [RFC][PATCH] module: Limit line length of module prints Rusty Russell <rusty@rustcorp.com.au> - 2015-12-11 10:50 +0100
      Re: [RFC][PATCH] module: Limit line length of module prints Laura Abbott <labbott@redhat.com> - 2015-12-11 23:30 +0100
    Re: [RFC][PATCH] module: Limit line length of module prints Laura Abbott <labbott@redhat.com> - 2015-12-11 23:30 +0100

#1289058 — [RFC][PATCH] module: Limit line length of module prints

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"?
---
 kernel/module.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index 8f051a1..ace82f1 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4059,11 +4059,14 @@ struct module *__module_text_address(unsigned long addr)
 }
 EXPORT_SYMBOL_GPL(__module_text_address);
 
+#define MAX_LINE_CHARS	80
+
 /* Don't grab lock, we're oopsing. */
 void print_modules(void)
 {
 	struct module *mod;
 	char buf[8];
+	int cnt = 0;
 
 	printk(KERN_DEFAULT "Modules linked in:");
 	/* Most callers should already have preempt disabled, but make sure */
@@ -4071,7 +4074,13 @@ void print_modules(void)
 	list_for_each_entry_rcu(mod, &modules, list) {
 		if (mod->state == MODULE_STATE_UNFORMED)
 			continue;
-		pr_cont(" %s%s", mod->name, module_flags(mod, buf));
+
+		if (cnt > MAX_LINE_CHARS) {
+			cnt = 0;
+			pr_cont("\n");
+		}
+
+		cnt += pr_cont(" %s%s", mod->name, module_flags(mod, buf));
 	}
 	preempt_enable();
 	if (last_unloaded_module[0])
-- 
2.5.0

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

[toc] | [next] | [standalone]

#1289365

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.

Cheers,
Rusty.

> ---
>  kernel/module.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 8f051a1..ace82f1 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -4059,11 +4059,14 @@ struct module *__module_text_address(unsigned long addr)
>  }
>  EXPORT_SYMBOL_GPL(__module_text_address);
>  
> +#define MAX_LINE_CHARS	80
> +
>  /* Don't grab lock, we're oopsing. */
>  void print_modules(void)
>  {
>  	struct module *mod;
>  	char buf[8];
> +	int cnt = 0;
>  
>  	printk(KERN_DEFAULT "Modules linked in:");
>  	/* Most callers should already have preempt disabled, but make sure */
> @@ -4071,7 +4074,13 @@ void print_modules(void)
>  	list_for_each_entry_rcu(mod, &modules, list) {
>  		if (mod->state == MODULE_STATE_UNFORMED)
>  			continue;
> -		pr_cont(" %s%s", mod->name, module_flags(mod, buf));
> +
> +		if (cnt > MAX_LINE_CHARS) {
> +			cnt = 0;
> +			pr_cont("\n");
> +		}
> +
> +		cnt += pr_cont(" %s%s", mod->name, module_flags(mod, buf));
>  	}
>  	preempt_enable();
>  	if (last_unloaded_module[0])
> -- 
> 2.5.0
--
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/

[toc] | [prev] | [next] | [standalone]

#1289956

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.
  
> Cheers,
> Rusty.
>

Thanks,
Laura
--
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/

[toc] | [prev] | [next] | [standalone]

#1289961

On 12/11/2015 01:36 AM, Geyslan G. Bem wrote:
> Hello,
>
> What do you think of get the strlen of name and module_flags before printing
>  them? So the check against MAX CHARS would be more precise and uniform. Or
>  the limit is not strictly necessary?

It's not really necessary. If it goes over a little bit that's okay. The goal
here is to try and introduce some reasonable wrapping.

Thanks,
Laura
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web