Re: Call for testing: emu10kx driver for Creative sound cards

From: Warner Losh <imp_at_bsdimp.com>
Subject: Re: Call for testing: emu10kx driver for Creative sound cards
Date: Tue, 23 May 2006 13:23:55 -0600 (MDT)

> From: Scott Long <scottl_at_samsco.org>
> Subject: Re: Call for testing: emu10kx driver for Creative sound cards
> Date: Tue, 23 May 2006 12:36:16 -0600
> 
> > Warner Losh wrote:
> > > From: Scott Long <scottl_at_samsco.org>
> > > Subject: Re: Call for testing: emu10kx driver for Creative sound cards
> > > Date: Tue, 23 May 2006 10:08:15 -0600
> > > 
> > > 
> > >>Dag-Erling Smørgrav wrote:
> > >>
> > >>>Alexander Leidinger <Alexander_at_Leidinger.net> writes:
> > >>>
> > >>>
> > >>>>Quoting des_at_des.no (Dag-Erling Smørgrav) (Tue, 23 May 2006 14:26:58 +0200):
> > >>>>
> > >>>>
> > >>>>>Yuriy Tsibizov <Yuriy.Tsibizov_at_gfk.ru> writes:
> > >>>>>
> > >>>>>
> > >>>>>>2. Complete mixer support. Some controls that can't fit into OSS
> > >>>>>>mixer are available as sysctl under debug.emu10kxX.
> > >>>>>
> > >>>>>That is not the correct place for it.  Please use the device's sysctl
> > >>>>>context (obtained with device_get_sysctl_ctx())
> > >>>>
> > >>>>This was based upon a suggestion by me. We want to get rid of most
> > >>>>sound related syscalls (at least those which belong into the realm of
> > >>>>the user, and not into the realm of the administrator). Until we have
> > >>>>an application and an interface, we have to life with the sysctls, but
> > >>>>to let the users know that this is not an interface but a temporary
> > >>>>workaround, it's put into the debug MIB. I hope we will not ship
> > >>>>7.0-RELEASE with any such sysctl (any help appreciated).
> > >>>
> > >>>
> > >>>Regardless, device-specific sysctl knobs belong in the individual
> > >>>device's sysctl context, which automatically places them in the
> > >>>correct location in the dev tree and automatically destroys them when
> > >>>the device is destroyed.  Please do not create further precedent for
> > >>>breaking this rule, no matter how good your intentions.
> > >>>
> > >>>DES
> > >>
> > >>The problem is that Alexander wants these sysctls to only be temporary.
> > >>Recall that big thread from a month or two ago about treating sysctls
> > >>as an API, and how there was heavy disagreement over how to define
> > >>"stable" sysctls that apps could depend on?  If a temporary set of 
> > >>sysctls get put under the dev tree, then it risks becoming permanent,
> > >>which is not what Alexander wants.  So, either we need to decide what
> > >>parts of the sysctl to define as stable, like I asked for in the 
> > >>previous thread, or we need to pretend that it's not a problem that we
> > >>should address, and let you and Alexander continue to argue over the
> > >>'correct place'.
> > > 
> > > 
> > > Then put them under the right place, but create a subtree that's "tmp"
> > > 
> > > In general, drivers should avoid using the debug.* space.
> > > 
> > > Warner
> > 
> > But that's the problem.  You just announced a rule that is in conflict
> > with rules that others have announced.  All I asked for was for the 
> > rules to be decided on and published, and I got pushback from people
> > who said either that all sysctls are part of the API, or that no rules
> > should exist and that everyone should just use careful judgement, so
> > long as their judgement is correct.  Both of these stances are absurd.
> 
> Drivers have no business using debug.* anymore.  They should migrate
> to the new interface that has already been in use, like DES said.
> Putting them in debug* doesn't make them any more or less permanant.
> The driver should document what is published and isn't published
> (approved, etc) in its man page.  In this case, adding a list of the
> 'blessed' sysctls to the appropriate man page with a warning that says
> that all others are for the convenience of the driver writer and may
> disapper would solve the problem.  Putting them under 'temp' or 'tmp'
> would also be a strong hint, but isn't completely necessary.

I guess the rules that I throught were agreed to when DES did his
sysctl additions to the newbus framework were:

	o All new driver sysctls should be attached to the node provided
	  by that framework.
	o Existing drivers were expected to migrate to that new
	  framework, providing compatibility goo if necessary for real
	  programs.

What should have been added was:
	o Drivers should document their sysctl interface in the man
	  page and indicate which parts of the interface are temporary
	  in nature and which parts are a committed part of the API.

While all sysctls could be considered to be part of the API, not all
sysctls are created equally.  There are some that are the well
documented place to get information.  There are some that are the well
used, but underdocumented place to get information.  There are many
that are there where information can be obtained, but few, if any,
consumers use it.  For the first two classes, we need to be careful to
avoid gratuitous api changes.  For the last class, we have
traditionally had the freedom to make changes for the convenience of
the developer.  The sysctls which were proposed for debug.emu10k*
clearly fall into the last category and as long as we document them as
such, it should be OK to change our minds later.

Somewhere between the two extremes that you pointed out is where we
should meet on consensus.  We should start with where the domain
experts thought the consensus arrived at last time and make changes
from there to reach a new consensus, rather than just invent something
totally new an random.

Anyway, that just my two cents.

Warner