Call for testing: emu10kx driver for Creative sound cards

Scott Long scottl at samsco.org
Tue May 23 19:49:09 UTC 2006


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 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.
> 
> Warner

That's fine (and I do agree with the content of you are saying), but 
that doesn't de-conflict the opposite advice that others have been 
giving.  I'd really like to see namespaces and name prefixes defined
that have stable/unstable meaning.  I dropped this due to the very
vocal opposition at the time.

Scott



More information about the freebsd-multimedia mailing list