Subject: Re: Reverting the PCMCIADEBUG removal?
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: None <jchacon@genuity.net>
List: tech-kern
Date: 05/20/2001 01:29:33
>
>Can't we defopt it, and rename it to PCMCIAVERBOSE-- or
>split it into VERBOSE parts, and acutal DEBUG parts?
>(Or PCMCIAINFO, if PCMCIAVERBOSE is already taken for something else?)
>
>I am not sure whether jhawk is asking only to have the extra info put
>back into INSTALL and GENERIC kernels, or if there is real desire to
>put back the machierny to use DDB to configure cards which woudln't
>otherwise be usable. 

Actually any of these can be done by setting the appropriate kernel options
still. All I did was turn off the hard coded, non-obviously editable case of
turning it on always. What jhawk appears to be objecting to is adding
"options PCMCIADEBUG" to the kernel config's he may find this useful in.
I'm unsure why this poses any problem as it's a hundred times cleaner and
much more consistant to any idea of an interface for these types of things.

This was why in the commit message I even mentioned folks should be setting
this via options PCMCIADEBUG as that's how a majority of any other debug
options are set. The goal here should be cleaner/simpler interfaces...

I still object to this going into GENERIC builds as there are zero other 
DEBUG style flags turned on there by default. Now, adding it in commented out
so it's an obvious flag is a completely separate thing and I doubt anyone
would object there. (the whole *DEBUG interface screams for something which
can find/document all of them into one common place).

>
>If there's really a desire to allow the DDB frobbing in
>INSTALL/GENERIC kernels, then can we invent a new defopt for just
>those parts?  Or does the ddb-frobbing require everything that real,
>honest-to-goodnes kernel debugging needs anyway?

No...At the point you're generally dropping to ddb to reset a debug var you're
probably doing to be using ddb for other things to break/watch/etc. The whole
idea of *DEBUG options having exposed debug vars to twiddle levels on via
ddb isn't a bad thing per se.

James