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

Dag-Erling Smørgrav wrote:
Alexander Leidinger <Alexander@xxxxxxxxxxxxx> writes:

Quoting des@xxxxxx (Dag-Erling Smørgrav) (Tue, 23 May 2006 14:26:58 +0200):

Yuriy Tsibizov <Yuriy.Tsibizov@xxxxxx> 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'.

Scott

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: dev.* analogue for interfaces
    ... Every time a device is registered, a sysctl context is automatically ... the driver - or even another driver - wants to add. ... interfaces aren't. ...
    (freebsd-arch)
  • Re: coretemp(4)/amdtemp(4) and sysctl nodes
    ... and I was looking at potentially removing them. ... the use in coretemp/amdtemp has me slightly stumped. ... you would want 'kldunload coretemp.ko' to remove the sysctl node even ... Probably these drivers should use a separate sysctl context. ...
    (freebsd-hackers)
  • dev.* analogue for interfaces
    ... I created the dev.* sysctl tree for device drivers. ... Every time a device is registered, a sysctl context is automatically ... the driver - or even another driver - wants to add. ... interfaces aren't. ...
    (freebsd-arch)
  • Re: Call for testing: emu10kx driver for Creative sound cards
    ... Subject: Call for testing: emu10kx driver for Creative sound cards ... 7.0-RELEASE with any such sysctl. ... device's sysctl context, which automatically places them in the ...
    (freebsd-current)
  • Re: Call for testing: emu10kx driver for Creative sound cards
    ... mixer are available as sysctl under debug.emu10kxX. ... device's sysctl context, which automatically places them in the ... We already have stuff in the debug MIB and there are even ideas ...
    (freebsd-current)