Reduce additional console output when muted #1407
Conversation
While trying to resolve some custom installer issues, we found that using conscontrol(8) or setting kern.always_console_output=0 in sysctrl.conf(5) did not always prevent console output. This is in part because some areas of the kernel were outputting to the console device without checking the status of the setting. These changes enforce checking of the value in both locations where console output occurs from kernel and init(8) based callouts. Details on changes: - Moves check for mute to earlier in sequence to silence kernel output even if EARLY_PRINTF is defined. - Modifies call prf_putbuf() and prf_putchar() in subr_prf.c to strip TOCONS flag if muting is enabled, to honor the setting at print level. This is a rather simple change, which increases areas where flags to silence console output are honored. We have been running this change since 10/23 in-house without issue. (Patching prior to 14.0 also required making cn_mute non-static.) Signed-off-by: Craig.Woodward@redcom.com
|
In the commit message, |
|
Adjusted |
While trying to resolve some custom installer issues, we found that using conscontrol(8) or setting kern.always_console_output=0 in sysctl.conf(5) did not always prevent console output. This is in part because some areas of the kernel were outputting to the console device without checking the status of the setting. These changes enforce checking of the value in both locations where console output occurs from kernel and init(8) based callouts. Details on changes: - Moves check for mute to earlier in sequence to silence kernel output even if EARLY_PRINTF is defined. - Modifies call prf_putbuf() and prf_putchar() in subr_prf.c to strip TOCONS flag if muting is enabled, to honor the setting at print level. This is a rather simple change, which increases areas where flags to silence console output are honored. We have been running this change since 10/23 in-house without issue. (Patching prior to 14.0 also required making cn_mute non-static.) Signed-off-by: Craig.Woodward@redcom.com
|
Missed the code changes. I'm a new to the process of pull requests here. Do I need to close this and open a new/clean pull request? The push/merge seems to have gone fine, but it's blocked on compute time limits? |
No worries! It is better to keep it on this same pull request.
Yes, usually the credits run out within the first few days of the month. Is it easy to add a before/after output? Or a way to easily reproduce the differences? |
Fine with a squash. I repeated the commit in the second update (with requested correction), for easier squashing.
The new delta is literally white-space fixes, so compile should be no different. That would be up to the committer I suppose, but seems unneeded for this delta if they're a scarce resource.
If you mean a clean diff from main to this (post fixes) then yes. I can generate it from our base tree vs our last merge point. But doing a checkout/patch/commit would remove the references already in this pull, would it not? If you mean a test-case for output this patch would block? That's harder. We found it when an app was trying to run when a library it wanted was not available. We could easily catch the error and setup a workaround. The problem was that the console output would show the library load failure, even when This area of the code has seen little change in the base tree for many years. The only "conflict" in pulling up to 14.0 was |
|
Since this has been marked "ready", is there anything more I need to do to get this into a main tree? I'm not super familiar with the process here, so just want to make sure I'm not missing a step to get changes merged in. |
|
I've been too busy this month to land things... I just need to make sure this boots (I'm 99% sure it will) and I'll commit it. |
While trying to resolve some custom installer issues, we found that using conscontrol(8) or setting kern.always_console_output=0 in sysctl.conf(5) did not always prevent console output. This is in part because some areas of the kernel were outputting to the console device without checking the status of the setting. These changes enforce checking of the value in both locations where console output occurs from kernel and init(8) based callouts.
Details on changes:
This is a rather simple change, which increases areas where flags to silence console output are honored. We have been running this change since 10/23 in-house without issue (Patching prior to 14.0 also required making cn_mute non-static.)
Signed-off-by: Craig.Woodward@redcom.com