Subject: Re: Reverting the PCMCIADEBUG removal?
To: John Hawkinson <jhawk@MIT.EDU>
From: None <firstname.lastname@example.org>
Date: 05/18/2001 11:58:17
So we should promote an inconsistant interface on *DEBUG's?
More than a few of them use it for DPRINTF in a much larger way than
pcmcia does. Just because pcmcia uses it in a small way is no real excuse
to include it by default while excluding others.
i.e. *DEBUG should be a better defined interface for folks to use and it
should be consistantly applied as to what gets turned on and how it gets
enabled. Having a #define off in some random source file vs. "options foo"
is horrible for consistancy reasons.
In this case you seem to be using the excuse that since the interface is not
defined we should explicitly do a one-off for pcmcia (and wdc then) since it's
convenient for you. However, since it adds *zero* value to the general end
user I still fail to see why the general end user should have it compiled
into their kernels by default with no easy way from the config to turn it off.
Especially when the config file is the defined place to use for setting kernel
options and configurations...
><email@example.com> wrote on Fri, 18 May 2001
>at 10:09:25 -0400 in <200105181409.KAA07731@dragon.tools.gtei.net>:
>> Enabled by default? We don't enable DEBUG by default and these also tend to
>> add more code/time to a system.
>I can't tell if you're ignoring my argument or just missing it,
>or seeing it differently.
>DEBUG has serious performance penalties and very little utility for
>most users or for INSTALL time. That's not the case with PCMCIADEBUG.
>I suspect it's not the case for WDCDEBUG, which is why abs proposed it.
>> Documenting them in a common way and providing an interface via "options" to
>> enable them sounds fine. Enabling them by default seems a horrible thing
>> to do to users for a GENERIC kernel. While that does have the kitchen sink
>> for options in it, it specifically doesn't have DEBUG turned on.