cap_mkdb: Fix memory leak
This is not a big deal since it only iterates once before exiting, but
that's no reason to set a bad example.
PR: 195128
MFC after: 1 week
Reviewed by: ngie
Differential Revision: https://reviews.freebsd.org/D57251
limits: Improve consistency
Historical precedent seems pretty consistent: size limits have singular
names, number limits have plural names. RLIMIT_VMM broke this, and I
made matters worse by referring to this limit as “vmms” in limits(1).
Consistently use “vms” everywhere user-visible, while leaving the
question of whether or not to rename RLIMIT_VMM itself for another day.
Fixes: 1092ec8b3375 ("kern: Introduce RLIMIT_VMM")
Fixes: 53af2026f213 ("limits: Unbreak after RLIMIT_VMM addition")
Reviewed by: bnovkov
Differential Revision: https://reviews.freebsd.org/D57265
hardware: update missing powerpc entries
Previous patch (4c396c5b7fd7) missed `archetypes/release/hardware.adoc`
which is used for creating new hardware notes. Update the file to
reflect the patch.
Reviewed by: cperciva
Fixes: 4c396c5b7fd7 ("hardware: Update pSeries entries")
Differential Revision: https://reviews.freebsd.org/D57260
www/freenginx-devel: update: 1.31.1 -> 1.31.2
Sponsored by: tipi.work
<ChangeLog>
*) Bugfix: a segmentation fault might occur in a worker process if
nested captures were used in the "rewrite" directive.
*) Bugfix: the "if" directive incorrectly handled relative paths when
checking files.
</ChangeLog>
sound: Retire snd_mixer->enuminfo
Instead of caching this when mix_setrecdevs() is called (which many
drivers never call), calculate it when we need it. After all, it is
quite rare that this structure is used by applications.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Retire MIXER_SIZE and use correct size in DEFINE_CLASS
I am not sure why this hack was needed, but the size should be
sizeof(struct snd_mixer). Unfortunately, we have to expose snd_mixer,
but it should be better than relying on a hack.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Remove all remaining uses of mixer_get_lock()
These functions are called from sound(4) through MIXER_SET() in
mixer_set(), but nothing mixer-related is used or needs to be locked in
these cases.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
snd_uaudio: Stop using mixer_get_lock()
There is no reason to lock snd_mixer->lock here, since the only thing we
are doing with snd_mixer is to call mix_getdevinfo() and mix_get_dev(),
which are one-line getters, which are needed to eventually call
uaudio_get_child_index_by_dev().
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
snd_uaudio: Do not use snd_mixer->lock as mixer_lock
In similar fashion to c234740c9d34 ("snd_uaudio: Do not use
pcm_channel->lock to protect uaudio_chan"), stop this layering
violation, and introduce a snd_uaudio(4)-internal mixer_lock.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Retire mixer_ioctl_channel()
This function never succeeds when it is not called from the same process
that has opened the file descriptor (e.g., mixer(8)). The reason is that
the CHN_FOREACH() loop tries to match the pid of each channel with the
pid of the process performing the ioctl, which will not be the same,
unless it's the same process that both opened the channel and performed
the ioctl.
In the case that the same process opens the channels and performs the
ioctl, however, we still do not need to worry, because mixer_ioctl_cmd()
essentially does the same thing anyway. Additionally, this scenario
should be quite rare, given that most applications do not open both
/dev/dsp* and /dev/mixer*, and in fact, it is actively encouraged by the
official OSSv4 specification not to do that.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Retire M_MIXER
Even though harmless, it is not really useful, as there is essentially
only one allocation with M_MIXER.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Retire hint.pcm.%d.eq_preamp
It wasn't documented in the first place, but it is easier to just use
the sysctl.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
sound: Remove dead EQ FEEDEQ_DISABLE code
If EQ is disabled, we never reach those code paths in the first place.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
sound: Retire FEEDEQ_DISABLE
We can do this more efficiently by just using the SD_F_EQ* flags. In
fact, the dev.pcm.%d.eq handler will (un)set SD_F_EQ_ENABLED and this is
what we actually test with when choosing to creating the EQ feeder or
not, so setting the state to FEEDEQ_DISABLE does not really an effect in
the first place.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
