Re: Debugging activated during runtime
On Oct 28 2007 17:07, Roel Kluin wrote: >Jan Engelhardt wrote: >> On Oct 28 2007 16:15, Roel Kluin wrote: >>> Wouldn't it be nice to be able to specify upon loading, or during runtime >>> to modules whether debug messages should be printed? >> >> modprobe ark3116 debug=1 >> >> Nothing new. > >Ok, thanks and sorry, I didn't know that. Loading debug info at runtime is more complex, and I doubt it is worth the time. If writing a module, carefully consider when to print what. When pr_*() comes in, this might be a bit relaxed. >>> - A module could be loaded after an unexpected conditions (e.g. after a >>> BUG_ON). >> >> After a BUG_ON, you are probably next to a panic. > >Not always, it appears. > But anything can happen. It might end in a panic. Or it might eat your data. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Debugging activated during runtime
Jan Engelhardt wrote: > On Oct 28 2007 16:15, Roel Kluin wrote: >> Wouldn't it be nice to be able to specify upon loading, or during runtime >> to modules whether debug messages should be printed? > > modprobe ark3116 debug=1 > > Nothing new. Ok, thanks and sorry, I didn't know that. >> - A module could be loaded after an unexpected conditions (e.g. after a >> BUG_ON). > > After a BUG_ON, you are probably next to a panic. Not always, it appears. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Debugging activated during runtime
On Oct 28 2007 16:15, Roel Kluin wrote: > >Wouldn't it be nice to be able to specify upon loading, or during runtime >to modules whether debug messages should be printed? modprobe ark3116 debug=1 Nothing new. >- No kernel recompile needed for debugging. >- Less *_DEBUG options required in menuconfig. > >How I think this could work: >Add to the module struct a bool to denote debugging state. If set, pr_debug >forwards messages to printk. > >Another advantage: >- A module could be loaded after an unexpected conditions (e.g. after a >BUG_ON). After a BUG_ON, you are probably next to a panic. >Caveats I can see right now: >- For modules often loaded during boot this may not be a good solution. > >Alternatively, instead of a bool for the debug state, the module struct could >also get a log-level flag: messages below that level won't be printed. What problem are you trying to solve? YOu can pass the module a parameter that can control how printk-verbose it will act. That is entirely in your hands, and it does not need to extend struct module. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Debugging activated during runtime
Wouldn't it be nice to be able to specify upon loading, or during runtime to modules whether debug messages should be printed? - No kernel recompile needed for debugging. - Less *_DEBUG options required in menuconfig. How I think this could work: Add to the module struct a bool to denote debugging state. If set, pr_debug forwards messages to printk. Another advantage: - A module could be loaded after an unexpected conditions (e.g. after a BUG_ON). Caveats I can see right now: - For modules often loaded during boot this may not be a good solution. Alternatively, instead of a bool for the debug state, the module struct could also get a log-level flag: messages below that level won't be printed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Debugging activated during runtime
Wouldn't it be nice to be able to specify upon loading, or during runtime to modules whether debug messages should be printed? - No kernel recompile needed for debugging. - Less *_DEBUG options required in menuconfig. How I think this could work: Add to the module struct a bool to denote debugging state. If set, pr_debug forwards messages to printk. Another advantage: - A module could be loaded after an unexpected conditions (e.g. after a BUG_ON). Caveats I can see right now: - For modules often loaded during boot this may not be a good solution. Alternatively, instead of a bool for the debug state, the module struct could also get a log-level flag: messages below that level won't be printed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Debugging activated during runtime
On Oct 28 2007 16:15, Roel Kluin wrote: Wouldn't it be nice to be able to specify upon loading, or during runtime to modules whether debug messages should be printed? modprobe ark3116 debug=1 Nothing new. - No kernel recompile needed for debugging. - Less *_DEBUG options required in menuconfig. How I think this could work: Add to the module struct a bool to denote debugging state. If set, pr_debug forwards messages to printk. Another advantage: - A module could be loaded after an unexpected conditions (e.g. after a BUG_ON). After a BUG_ON, you are probably next to a panic. Caveats I can see right now: - For modules often loaded during boot this may not be a good solution. Alternatively, instead of a bool for the debug state, the module struct could also get a log-level flag: messages below that level won't be printed. What problem are you trying to solve? YOu can pass the module a parameter that can control how printk-verbose it will act. That is entirely in your hands, and it does not need to extend struct module. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Debugging activated during runtime
Jan Engelhardt wrote: On Oct 28 2007 16:15, Roel Kluin wrote: Wouldn't it be nice to be able to specify upon loading, or during runtime to modules whether debug messages should be printed? modprobe ark3116 debug=1 Nothing new. Ok, thanks and sorry, I didn't know that. - A module could be loaded after an unexpected conditions (e.g. after a BUG_ON). After a BUG_ON, you are probably next to a panic. Not always, it appears. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Debugging activated during runtime
On Oct 28 2007 17:07, Roel Kluin wrote: Jan Engelhardt wrote: On Oct 28 2007 16:15, Roel Kluin wrote: Wouldn't it be nice to be able to specify upon loading, or during runtime to modules whether debug messages should be printed? modprobe ark3116 debug=1 Nothing new. Ok, thanks and sorry, I didn't know that. Loading debug info at runtime is more complex, and I doubt it is worth the time. If writing a module, carefully consider when to print what. When pr_*() comes in, this might be a bit relaxed. - A module could be loaded after an unexpected conditions (e.g. after a BUG_ON). After a BUG_ON, you are probably next to a panic. Not always, it appears. But anything can happen. It might end in a panic. Or it might eat your data. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
