set_dprintf_enabled() always enables serial debugging

[jkloetzke]

The function set_dprintf_enabled() always enables serial debug output unconditionally. This is somewhat confusing if this is was switched off in the kernel settings.

Especially it may be sometimes neccessary to _not_ use serial debugging but use the syslog method because dprintf is very slow on serial lines and the corresponding thread uses massive amounts of CPU time to wait on serial line. Furthermore the machine may have no serial output at all.

[axeld]

That's exactly what this function is supposed to do (and that's also how it works under BeOS) - you can easily turn off serial debugging and turn on syslog output in the kernel settings file if you need that setup. There are very few cases where one would need that function, anyway.

[jkloetzke]

Replying to axeld:

That's exactly what this function is supposed to do (and that's also how it works under BeOS) - you can easily turn off serial debugging and turn on syslog output in the kernel settings file if you need that setup. There are very few cases where one would need that function, anyway.

Maybe I didn't understand the function right. ;-)

My problem was the following: I enabled debug outputs of the USB stack and (because my laptop has no serial port) I wanted to route the dprintf() messages to syslog only. I configured the kernel settings accordingly but found out that the serial output was still active which caused the USB stack to use massive amounts of CPU time.

I found that set_dprintf_enabled(true), which was called from src/add-ons/kernel/bus_managers/usb/usb.cpp, enabled the serial output again, even though it was disabled in the kernel settings. Looking at the BeBook dprintf() is disabled by default, so the USB stack should call set_printf_enabled(true) as far as I understand. Therefore I submitted this bug because it seems that eighter the USB stack is wrong by calling set_dprinf_enabled(true) (which I do not think) or the kernel settings file should have the alone authority about the dprinf() routing.

[axeld]

How should set_dprintf_enabled() know which output it should enable? If you've enabled the syslog output in the settings, it will just work. The USB stack is not doing the right thing here, at least not if it didn't intend to turn on serial debug output.

[jkloetzke]

Ok, then I was really fooled by the name of the function. I thought that if you doesn't call it then dprintf is a no-op. You're right, then the USB stack is wrong at this point.

BTW: a couple of other drivers call this function too when debug is enabled for them...