Internally libyuv uses malloc & free for short time dynamic memory
allocation during image transformation. The converted images are
such large, that the Libc allocator will create and destroy new Genode
dataspace per image. In time sensitive code paths, the overhead can be
noticeable by the caller of the image transformation.
The patch adds the option to register callbacks in the libyuv library to
implement the image allocation by users of the library. They may implement
caching strategies to avoid the overhead, e.g. as seen with qemu-usb and
the webcam model.
and not before. On Windows guest with more than 1 vCPU, the packets
seem to arrive and/or seem to be handled too late in the Webcam model.
An intermediate state, to due the late packet, has been used to decide to
close the Capture session too early.
Dynamically loading the `compat-libc` breaks `fork(2)` on Genode.
Switch `compat-libc` to a special api package that provides a source
file for statically linking the library, analogous to the `blit`
package. This also requires a quirk in Goa but should prevent breaking
`fork()` and removes the runtime and archive dependencies for Rust
packages using `compat-libc`.
Ref genodelabs/goa#61
Implement FBSD_1.0 versions of libc functions ('stat', 'fstat'). The
functions are versioned with @FBSD_1.0, and therefore, will not clash
with libc during linking. However, to be called by our dynamic linker,
the library must be before libc in the NEEDED section of the binary
using it. This requires the lib to be in front of libc in the LIBS
variable. The library currently will call libc 'stat' and 'fstat' by
looking up the symbols via 'dlsym'.
Ref genodelabs/goa#61
In case the meta data (or more) got zeroed upon 'free', print error
message. The offset in the meta data can never be zero. This does not
help on other memory corruptions, but at least gives a hint in the too
much zeroed out case.
issue #4675
The XHCI model reserves 0x4000 of IO memory but uses only 0x530.
Implement read (0) and write (nop) for these regions as real hardware
does.
fixes#4902
This patch solves the false-negative error message "failed to open file"
referring to an ioctl info file during an ioctl call. The message is
now avoided by checking for the existence of the file before reading it.
However, the observed symptom uncovered an actual bug that was
introduced in commit "libc vfs: open OSS 'info' file only once" with
the attempt to cache the content of ioctl info files. When called
multiple time for different paths, 'Vfs_plugin::_with_info' would
wrongly return the info from the first call as cached in a local
static variable.
The patch fixes the problem by a new added 'Cached_ioctl_info'
implementation in the scope of the 'Vfs_plugin'.
Issue #4372Fixes#4852
- move metadata specific to isochronous transfers from the descriptor
into the content of USB-session packets
- restore support for 32 in-flight packets in the USB C API
Fixes#4749
This little library implements rudimentary format-string support. It is
useful for porting 3rd-party code that ought not depend on a full libc.
Issue #2064
In case the packet is erronous the value of 'actual_size' can be
invalid and using it may lead to a page-fault due to out-of-bounce
access.
With this commit access is only performed on successful packets.
Fixes#4763.
The 'file_size' type denotes the size of files on disk in bytes. On
32-bit architectures it is larger than the size_t, which refers to
in-memory object sizes.
Whereas the use of 'file_size' is appropriate for ftruncate and seek, it
is not a suitable type for the parameters of read/write operations
because those operations refer to in-memory buffers.
This patch replaces the use of 'file_size' by size_t. However, since it
affects all sites where the read/write interface is uses, it takes the
opportunity to replace the C-style (pointer, size) arguments by
'Byte_range_ptr' and 'Const_byte_range_ptr'.
Issue #4706
Prior to this change the libdrm Lima implementation supported the
creation of multiple contexts where each context, however, was
treated as the same client like it was done in the Lima driver
itself.
With this commit each context becomes its own client while the
main context always performs all buffer object related allocation
and the other context import each needed BO before submitting.
Fixes#4760.
