Subject: Re: DPRINTF in ?
To: Iain Hibbert <plunky@rya-online.net>
From: Quentin Garnier <cube@cubidou.net>
List: tech-kern
Date: 03/17/2007 01:41:24
--BeiMt4EphvRJ5ehf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 16, 2007 at 10:48:29PM +0000, Iain Hibbert wrote:
> On Fri, 16 Mar 2007, Quentin Garnier wrote:
>=20
> > On Fri, Mar 16, 2007 at 10:06:39AM +0000, Iain Hibbert wrote:
> > > 	debug <attribute> [<level>]
> >
> > You don't mention where you intend to put such lines, in the
> > specification part (files.*) or in the user-edited selection part.
> >
> > Guts says specification part (IMO, that's where it belongs anyway).
>=20
> No, in the user edited..  so that it would be far easier to enable
> debugging on a driver or module. Its often fiddly to enable debugging
> output, as you have to find the correct source file to place the XXX_DEBUG
> definition, and even then it doesn't always work properly.
>=20
> I was not going to modify the files.* specifications - my thought was that
> if this piggybacked on the attributes that are already used, they don't
> need to be extended at all..

The thing you're missing is that attributes are not something the user
always sees.  E.g., ep* at isa? brings in attribute ep_isa and ep.  If
you want debug for the ISA attachment, it's different from debug for the
rest of the driver.  Yes, it's far fetched, but there are probably
better examples of the issue.

[...]
> > 1. subsystems define their debug stuff in files.whatever
> >    brought in along with the sysctl hierarchy when user do 'options
> >    DEBUG'.  Note that the user still has fine-grained control over the
> >    messages because it does the selection through sysctl.  However,
> >    messages in all subsystems are potentially available.
>=20
> Hmm, you mean to make a single 'options DEBUG' include debugging for *all*
> subsytems in the kernel?

Well, that's what DEBUG is for, after all, isn't it?  I think that
you'll find already quite a few subsystems using #ifdef DEBUG for that
kind of stuff.

> That would be an alternate destination than the one I had in mind, but it
> would mean you could easily generate a GENERIC_DEBUG kernel, which would
> potentially be more useful as long as performance did not suffer hugely.
>=20
> in that case, a sysctl heirarchy could be built automagically based on
> file names: "sysctl -w debug.dev.wscons.wsmouse=3D3" and no modification =
to
> files.* need be made. Do you see something better?

Well, I don't really understand why you're reluctant to change files.*.
If it is a property of a driver, then it is where it belongs.  However,
the user-editable part of the config file may contain any of the
statements that you normally find in files.*, so it's something that can
start in a GENERIC_DEBUG and spreads over the tree smoothly.

Another reason to have this in files.* is that it automatically applies
to all archs.

And there can be other things, too, like the "debug" statements allowing
an "options DEBUG_<attr>" in the user-edited part.  I don't like it much
though;  I'd rather have something plain and simple for the end user.

In the end I see all this as much more useful for a user that needs to
send info on a list or in a PR than for a developer working on a bug on
his own system.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

--BeiMt4EphvRJ5ehf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iQEVAwUBRfs5NNgoQloHrPnoAQKPiAgAr+FOLsf6ADa3uWlHmjOq888hD84utuUr
w1AfaYP2MZvBmTWav79I8HyBOWJCt+KslQ/g9qX2XN8X3ayjJGwKJ+wMlUZG1BPK
G79QR6Xprxx0Ub8zE5LM60yVwuWngD8IZuEDQMtdZTHnZiE4eVxI414slzpAU0zs
wppmVhhh3Or9frYJZwIf/8fuM5vN012VzLeKMgMamvhgRtRHicrA3QSigCWTlyg1
Saj9SL4g72vLG5Z9GFUxbqLYC3Qzcgi+BBq2vasYWuJMyCVdTSVkWs6nBLyC/f7c
FnExk/IonPa8zyDdaSrMIMlOCOGhYp/P7SaOV8JFl7OHmdx8DHSC6w==
=nzun
-----END PGP SIGNATURE-----

--BeiMt4EphvRJ5ehf--