cifs: Do not enable debugging code by default
Subsystems (2)
PATCH 1/1 cifs: Do not enable debugging code by default
Debugging code is generally disabled in the configurator since it is only for devs and testers and not for the majority of the installations.
--- fs/cifs/Kconfig | 1 - 1 file changed, 1 deletion(-)
fs/cifs/Kconfig +0 -1
@@ -124,7 +124,6 @@ config CIFS_ACL config CIFS_DEBUG bool "Enable CIFS debugging routines" - default y depends on CIFS help Enabling this option adds helpful debugging messages to
Signature · 1 line
1.8.1.rc2
I don't think taking out debugging makes sense - we need debugging a lot more often than expected even to diagnose user errors (usually relating to session establishment failures, since we are very limited
in how much information can be passed back in mount). If we had
dynamic trace points for cifs and for common vfs entry points, or if the distros shipped dual cifs modules (one with debugging and one without), I wouldn't mind disabling it - but multiple times a month we have to diagnose user problems (sometimes user errors, sometimes server bugs etc.) by enabling debugging.
Quoted 31 lines · Borislav Petkov
Debugging code is generally disabled in the configurator since it is only for devs and testers and not for the majority of the installations.
Cc Joe Perches <[email protected]>Cc Jeff Layton <[email protected]>Cc Steve French <[email protected]>Signed-off-by Borislav Petkov <[email protected]>--- fs/cifs/Kconfig | 1 - 1 file changed, 1 deletion(-)fs/cifs/Kconfig +0
-2@@ -124,7 +124,6 @@ config CIFS_ACL config CIFS_DEBUG bool "Enable CIFS debugging routines" - default y depends on CIFS help Enabling this option adds helpful debugging messages to --1.8.1.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 3 lines
Thanks, Steve
Quoted 29 lines · On Mon, 17 Dec 2012 09:30:33 -0600 Steve French…
I don't think taking out debugging makes sense - we need debugging a lot more often than expected even to diagnose user errors (usually relating to session establishment failures, since we are very limited
in how much information can be passed back in mount). If we had
dynamic trace points for cifs and for common vfs entry points, or if the distros shipped dual cifs modules (one with debugging and one without), I wouldn't mind disabling it - but multiple times a month we have to diagnose user problems (sometimes user errors, sometimes server bugs etc.) by enabling debugging.Quoted 18 lines · Borislav Petkov
Debugging code is generally disabled in the configurator since it is only for devs and testers and not for the majority of the installations.
Cc Joe Perches <[email protected]>Cc Jeff Layton <[email protected]>Cc Steve French <[email protected]>Signed-off-by Borislav Petkov <[email protected]>--- fs/cifs/Kconfig | 1 - 1 file changed, 1 deletion(-)fs/cifs/Kconfig +0
-0@@ -124,7 +124,6 @@ config CIFS_ACL
Quoted 9 lines
Quoted 9 lines
fs/cifs/Kconfig +0
-2config CIFS_DEBUG bool "Enable CIFS debugging routines" - default y depends on CIFS help Enabling this option adds helpful debugging messages to --1.8.1.rc2
I agree that we often need cifsFYI debug info in order to troubleshoot problems. The question here though is whether compiling those in ought to be the default.
In generic distro kernels, I think we do want that turned on even in non-debug kernels. On an embedded arch, it's less compelling.
Might it make sense to couple this change with a change to the CONFIG_CIFS_DEBUG help text? Something like:
"This option defaults to 'N', but enabling this is strongly encouraged unless memory is severely constrained."
Then we can just try to make sure non-embedded distros enable it.
Signature · 1 line
Jeff Layton <[email protected]>
Quoted 4 lines · Jeff Layton
I agree that we often need cifsFYI debug info in order to troubleshoot problems. The question here though is whether compiling those in ought to be the default.
Quoted 8 lines
In generic distro kernels, I think we do want that turned on even in non-debug kernels. On an embedded arch, it's less compelling.
Might it make sense to couple this change with a change to the
CONFIG_CIFS_DEBUGhelp text? Something like:"This option defaults to 'N', but enabling this is strongly encouraged unless memory is severely constrained."
... or we make it default n if EMBEDDED, otherwise default y + changing the help text?
Quoted 1 line
Then we can just try to make sure non-embedded distros enable it.
Yeah, I don't think distros look at the help text... or?
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--Quoted 14 lines · On Tue, 18 Dec 2012 15:44:52 +0100 Borislav Petkov…
Quoted 4 lines · Jeff Layton
I agree that we often need cifsFYI debug info in order to troubleshoot problems. The question here though is whether compiling those in ought to be the default.
Quoted 8 lines
In generic distro kernels, I think we do want that turned on even in non-debug kernels. On an embedded arch, it's less compelling.
Might it make sense to couple this change with a change to the
CONFIG_CIFS_DEBUGhelp text? Something like:"This option defaults to 'N', but enabling this is strongly encouraged unless memory is severely constrained."
Quoted 7 lines
... or we make it default n if EMBEDDED, otherwise default y + changing the help text?
Quoted 1 line
Then we can just try to make sure non-embedded distros enable it.
Yeah, I don't think distros look at the help text... or?
Yeah, not many do, but presumably they'll set it once and forget about it. Once someone straightens them out, they should rarely break.
OTOH, the value of defaulting to "N" is pretty low here. Maybe it would just be best to just drop this patch and have the embedded folks turn this off on their own.
Signature · 1 line
Jeff Layton <[email protected]>
Quoted 6 lines · Jeff Layton
Yeah, not many do, but presumably they'll set it once and forget about it. Once someone straightens them out, they should rarely break.
OTOH, the value of defaulting to "N" is pretty low here. Maybe it would just be best to just drop this patch and have the embedded folks turn this off on their own.
Yeah, sure.
I just thought you have this debugging code forked out of the driver and it should be enabled only for when there are issues.
Thanks.
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--Quoted 9 lines · Borislav Petkov
Quoted 6 lines · Jeff Layton
Yeah, not many do, but presumably they'll set it once and forget about it. Once someone straightens them out, they should rarely break.
OTOH, the value of defaulting to "N" is pretty low here. Maybe it would just be best to just drop this patch and have the embedded folks turn this off on their own.
Yeah, sure.
I am ok with disabling it for embedded, but probably easier to drop
it. The real benefit will come when someone familiar with dynamic
trace points comes up with some good examples for file system(s) and the VFS so we can reduce our dependency on static tracing.
Signature · 3 lines
Thanks, Steve
vfs trace points?: was: cifs: Do not enable debugging code by default
Quoted 9 lines · Steve French
Quoted 8 lines · Borislav Petkov
Quoted 6 lines · Jeff Layton
Yeah, not many do, but presumably they'll set it once and forget about it. Once someone straightens them out, they should rarely break.
OTOH, the value of defaulting to "N" is pretty low here. Maybe it would just be best to just drop this patch and have the embedded folks turn this off on their own.
Quoted 6 lines
Quoted 1 line
Yeah, sure.
I am ok with disabling it for embedded, but probably easier to drop
it. The real benefit will come when someone familiar with dynamic
trace points comes up with some good examples for file system(s) and the VFS so we can reduce our dependency on static tracing.
I'm fine with requiring embedded to turn this off
where appropriate.
It seems that keeping cifs KERN_DEBUG output for normal kernels is pretty cost free. 120KB ain't much these days.
I do think that Al Viro & Ted Ts'o should be pinged about their vfs tracing thoughts. (cc'd)
MIT seems to bounce my emails, so maybe you could ask Ted directly.