>
>jchacon@genuity.net <jchacon@genuity.net> wrote on Fri, 18 May 2001
>at 11:58:17 -0400 in <200105181558.LAA08374@dragon.tools.gtei.net>:
>
>> So we should promote an inconsistant interface on *DEBUG's?
>
>Essentially -- yes. We have never had such a consistent interface,
>and we should be loathe to carefully consider the consequences of
>forcing one.
>
>Further, it should be done in a careful thoughtful fashion. Requiring
>a consistent interface is not a good reason to change one of them and
>leave all the others.

In making this change it makes that code consistant with everything else
and doesn't prevent you or anyone else who wants to not have the ability
to re-enable immmediately with options PCMCIADEBUG. 

It's a larger win all around then simply due to the ability to control it as 
options should be (from the config file) rather than buried off in some 
random source file. In addition not forcing every user to compile in additional
needless code (for a majority of them this sort of code ranks right there)
is an additional win.

>
>> 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 do not understand this argument.

Keeping the *DEBUG interface somewhat consistant is a much better thing to
try and accomplish here (which I'd love to discuss as an overall thing) rather
than piece-mealing it into "well for X I like it that way so please leave it".

>
>> 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
>
>It (and perhaps more importantly PCMCIACISDEBUG) do not add zero value.
>It may be important for non-developers to be able to turn them on
>to perform useful debugging and useful communications with developers
>without requiring custom kernels.

I'll be honest here. I doubt it. I'll bet a large sum of money that never
happens for anyone except a developer who also happens to do kernel hacking.
By the time you're turning them on to "perform useful debugging" you've crossed
well over the line of average end-user. Not many end-users are going to
understand PCMCIA specifics like functions, CIS, etc. The general end user at 
best is going to file a PR and/or send mail to current-users. Then if a 
developer wants to assist it's rather simple to ask for full debugging to be 
compiled in.

I run kernels all the time with DEBUG, DIAGNOSTIC, -g, *DEBUG options set. Yes
it's convenient for me when I'm debugging something. But would I expect a 
general user asking me for help to have the same setup? No way. Asking them
to include extra overhead as a default so on the off chance you might get 
called to help debug something seems a high price for them to be paying.

Extending this then would you also be expecting them to have DEBUG set? That
also tends to trigger a lot of other checks/vars/etc depending on 
implementation but I doubt anyone seriously expects the release to have that
one by default (and they don't).

The whole kernel tree should by default be presuming a build for a production
end system that is fast/lean/clean. Additional debugging overhead that isn't
controllable as to it's on/off state from the config file is adding overhead
to every user for a possible benifit to a small few.

I agree PCMCIADEBUG doesn't add much, but the precendent is horrible and unless
some sort of consistancy is kept more and more things like this creep in and
we slide farther and farther back on the performance scales. (as we've been
doing for some time).


>
>Perhaps this is an architectural flaw, but if so, that flaw should
>be correced before the useful mechanism is removed.

If there was no other way to set this up I'd agree, but how hard is it
to use "options PCMCIADEBUG"? Especially when almost every other debug type
option uses that exact interface. Using the principle of least surprise one
would expect to set it that way, when instead with the method you want I
get zero control over that unless I happen to go edit the source file
(which now affects every kernel I build for every arch).

This definitly fails that litmus test under those conditions.

>
>> 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...
>
>You seem to be ignoring my assertion that these are valuable to
>non-developers. Do you disagree? Do you find my argument insufficient?
>Explain, please.
>

I have explained. You can counter with "why is it so hard to now set
options PCMCIADEBUG"? Espceially when that's the documented interface for
setting/unsetting compile time options for items in this vein.

James