- unlink shared memory files
- lower maximum number of socket pool sockets to reduce chance of file
descriptor exhaustion
- fix a build dependency which caused sporadic parallel build errors
Fixes#3910
With this commit, the alignment of anonymous 'mmap()' allocations can be
configured like this:
<config>
<libc>
<mmap align_log2="21"/>
</libc>
</config>
Fixes#3907
This plugin gives access to the Audio_out session by roughly
implementing a OSS pseudo-device. It merely wrapps the session and does
not provide any resampling or re-coding.
Fixes#3891.
In the same vein as the terminal and block I/O controls, the sound
controls are implemented via poperty files and match the OSS
API ([1] features a nice overview while [2] is v3 and [3] gives
in-depth information on the current v4.x API we eventually might want
to implement).
[1] https://wiki.freebsd.org/RyanBeasley/ioctlref/
[2] http://www.opensound.com/pguide/oss.pdf
[3] http://manuals.opensound.com/developer/
The controls currently implemented are the ones used by the cmus OSS
output plugin, which was the driving factor behind the implementation.
It uses the obsolete (v3) API and does not check if the requested
parameter was actually set, which should be done according to the
official OSS documentation.
At the moment it is not possible to set or rather change any
parameters. In case the requested setting differs from the parameters
of the underlying Audio_out session - in contrast to the suggestion in
the OSS manual - we do not silently adjust the parameters returned
to the callee but outright fail the I/O control operation.
The following list contains all currently handled I/O controls.
* SNDCTL_DSP_CHANNELS sets the number of channels. We return the
available channels here and return ENOTSUP if it differs from
the requested number of channels.
* SNDCTL_DSP_GETOSPACE returns amount of playback data that can
be written without blocking. For now it amounts the space left
in the Audio_out packet-stream.
* SNDCTL_DSP_POST forces playback to start. We do nothing and return
success.
* SNDCTL_DSP_RESET is supposed to reset the device when it is
active before any parameters are changed. We do nothing and return
success.
* SNDCTL_DSP_SAMPLESIZE sets the sample size. We return the
sample size of the underlying Audio_out session and return ENOTSUP
if it differs from the requested number of channels.
* SNDCTL_DSP_SETFRAGMENT sets the buffer size hint. We ignore the
hint and return success.
* SNDCTL_DSP_SPEED sets the samplerate. For now, we always return
the rate of the underlying Audio_out session and return ENOTSUP
if it differs from the requested one.
This commit serves as a starting point for further implementing the
OSS API by exploring more users, e.g. as VirtualBox/Qt5/SDL2 audio
backend or a more sophisticated progam like sndiod.
Issue #3891.
At least on some PIT-based platforms (x86_32 + pistachio/okl4/sel4), we run
into trouble with the reworked timeout framework that now proccesses all
pending timeouts before calling their handlers. This order change leads to a
higher rate of handling of short periodic timeouts in the timer driver which
can cause lower prioritized components to starve. Especially, if submitting
signals (from timer to client) isn't cheap (as is the case on qemu + pistachio
for example).
Issue #3884
The driver is faily simple and does not support fancy features like
TCP checksum offloading or vlan filtering, but it is fully capable of
running every Genode network based scenario I've tried. Its currently
known to work on virt_qemu arm platforms and x86_64.
Fix#3825
To simplify writing native VirtIO drivers for Genode add helper classes
representing VirtIO device and queue. The queue implementation should
be platform independant. The device abstraction however is closely tied
to the VirtIO transport being used (PCI/MMIO). Both PCI and MMIO
implementations expose the same public API so the actual driver logic
should be the same regardless of which transport is used.
Its also important to note that the PCI version of Virtio::Device
currently does not support MSI-X interrupts. Unfortunately my kowledge
about PCI bus is very limited and my main area of interest was to get
VirtIO drivers working on virt_qemu ARM/Aarch64 platform. As such all
the VirtIO drivers I plan to submit will work with PCI bus, but might
not use some extended capabilities.
Ref #3825
The VirtIO device configuration on Qemu is dynamic. The
order and presence of different command line switches affects
base address and interrupt assignment of each device. One could
probably hard-code the necessary switches and resulting XML ARM
platform driver configuration in each run script, but this seems
like troublesome and hard to maintain solution.
This patch explores an alternative approach to the problem.
It implements a ROM driver which probes the address space region
Qemu virt machines assign to VirtIO MMIO devices and exposes the
result as XML via a ROM session. This XML output can be fed directly
as config to the generic ARM platform driver.
Ref #3825
Right now the same code dealing with nic setup on qemu is duplicated
in many different run scripts. It makes it unnecesarily complex to
change the existing config or add support for new nic types. Lets move
all this common code to qemu.inc.
Ref #3825
- make GPIO server more robust on imx by not throwing exceptions for
unknown pins, use '_with_gpio' instead
- use 'Gpio::Pin' data type instead of POD 'unsigned'
issue #3900
The patch handles the case, that the memory for the MSI-X table is part
of one of the Pci::Resource Memory BARs, which got allocated beforehand already.
With this commit, the platform driver will not fall back to use legacy IRQs or MSI, whereby MSI-X is available actually. Additionally, this patch avoids a lot of red
messages about non available IO-MEM printed by the roottask.
Fixes#3904
The deadlock occured with three concurrently running threads: two
waiters calling pthread_cond_timedwait() and one signaller calling
pthread_cond_signal().
If waiter W1 hits its timeout, the signaller may have called
pthread_cond_signal(), detected this waiter and posted the internal
'signal_sem' concurrently. Then, the signaller waits for 'handshake_sem'
to ensure the waiter got woken up.
Waiter W1 can't consume the 'signal_sem' post by
'sem_wait(&c->signal_sem)' because another waiter W2 may have consumed
the post already above in sem_wait/timedwait(). Waiting for a post on
'signal_sem' would block the waiter W1 in perfect deadlock with
signaller on 'handshake_sem'. As W1 also owns 'counter_mutex' in this
situation, waiter W2 would block when trying to aquire 'counter_mutex'
and can't resolve the situation.
So, W1 does nothing in this case and we accept the spurious wakeup on
next pthread_cond_wait/timedwait().
