The new 'Env::try_session' method mirrors the existing 'Env::session'
without implicitly handling exceptions of the types 'Out_of_ram',
'Out_of_caps', 'Insufficient_ram_quota', and 'Insufficient_cap_quota'.
It enables runtime environments like init to reflect those exceptions to
their children instead of paying the costs of implicit session-quota
upgrades out of the own pocket.
By changing the 'Parent_service' to use 'try_session', this patch fixes
a resource-exhaustion problem of init in Sculpt OS that occurred when
the GPU multiplexer created a large batch of IO_MEM sessions, with each
session requiring a second attempt with the session quota upgraded by
4 KiB.
Issue #3767
This commit removes the report service from the usb_webcam pkg, which
was used to enable or disable the webcam driver. The on/off state is
instead controlled by the presence of a capture client. That is, once a
capture client appears, the webcam driver is started. Vice versa, once
no capture client exists, the webcam driver is removed automatically.
Internally, the detection of presence of a capture client is based on
nitpicker's 'displays' report, which is consumed as input of the
rom_filter, which in turn generates the configuration of a dynamic sub
init.
Fixes#4287
'Out_of_ram' was so far the only exception a client had to deal with
during buffer managment. Allocating memory, however, does not only
consume RAM quota but CAP quota as well.
This commit tries to mitigate that shortcoming by reflecting the
'Out_of_caps' state back to the client. Furthermore it allows for
resource accounting on certain client allocations, e.g. buffers.
Fixes#4284.
By using the cached_fs_rom instead of fs_rom, each client obtains the
same (read-only) copy of the shared library, avoiding a RAM resource
request when running mulitple GPU applications at the same time.
With this patch, Sculpt is able to host at least 3 Mesa applications.
Issue #4263
Issue #4281
This new version of the system_clock pkg does no longer depend on the
presence of an external 'Rtc' service as previously provided by the
Sculpt base system. Instead, it hosts the rtc_drv inside the subsystem.
Because rtc_drv is board-dependent, the system_clock pkg is named
system_clock-pc now.
Issue #4281
Some guests don't handle remote wake up correctly causing devices to
stop functioning. Therefore, we disable the remote wake up bit (5) in
`bmAttributes` of the device configuration descriptor.
Thanks to Peter for the initial fix.
Fixes#4278
The various mapping methods are modelled after the requirements of
the Intel GPUs or rather the Mesa driver back end.
With upcoming support for other driver back ends, we need to
sequeeze their requirements in as well. For now hijack 'map_buffer'
to provide for specifying the kind of attributes the client needs.
For now all buffers mapped in the GGTT for Intel GPUs are treated
as RW.
Issue #4265.
This call allows for checking if the given execution buffer has been
completed and complements the completion signal. Initially the GPU
multiplexer always sent such a signal when the currently scheduled
execution buffer has been completed. During enablement of the 'iris'
driver it became necessary to properly check of sequence number.
In case of the Intel GPU multiplexer the sequence numbers are
continous, which prompted the greater-than-or-equal check in the
DRM back end. By hidding this implementation detail behind the
interface, GPU drivers are free to deal with sequence numbers any
way they like and allows for polling in the client, where the
completion signal is now more of a progress signal.
Issue #4265.
The current info implementation (as RPC) is limited in a few ways:
* The amount of data that may be transferred is constrained by the
underlying base platform
* Most information never changes during run time but is copied
nonetheless
* The information differs depending on the used GPU device and
in its current implementation only contains Intel GPU specific
details
With this commit the 'info' RPC call is replaced with the
'info_dataspace' call that transfers the capability for the dataspace
containing the information only. This is complemented by a client
local 'attached_info' call that allows for getting typed access to
the information. The layout of the information is moved to its own
and GPU-specific header file, e.g., 'gpu/info_intel.h'
Issue #4265.
Rather than using the dataspace capability directly, let the client
choose its own local identifier that is linked to the underlying
capability.
Fixes#4265.
* Wait for for completion before return from 'execbuffer2'. This makes
buffer execution synchronous.
* Because the Iris driver manages the virtual address space of the GPU
and creates one GEM context for each batch buffer we have to map/unmap
all buffer objects before and after batch buffer execution.
issue #4260
This patch adds a switch to internal poll function in libssh that
allows to force this function to immediately return without actually
polling for data and in consequence processing this data. This switch
is used to avoid calling callback functions when flushing output
streams which caused locks due to recursive access to internal
ssh_terminal sessions registry.
Issue #4258
This patch allows to replace sftp packet read and write with
completely asynchronous versions needed to properly hook in existing
ssh_terminal implementation.
Issue #4258
* Switch mesa support from DRI to gallium
Supported drivers are
- softpipe (Sebstian Sumpf)
- iris for Intel GPUs (Alexander Boetcher)
- etnaviv for Vivante GPUs (Josef Söntgen)
* Mesa's generated files are placed into 'contrib/mesa-<hash>/generated'
and are cloned per default from a separate Git repo in order to avoid
hash updates upon package build. In case you need to generate files
yourself use
! prepare_port mesa GENERATE_FILES=1
issue #4254
Support for iris and etnvaviv
* entaviv:
- libdrm on FreeBSD is not prepared for !PCI (and libc our is missing
<sys/pciio.h>
- missing <sys/types.h> include in xf86drmMode.c
- etnaviv relies on linux header files - dummy in $(INC_DIR)
- IOCTL FreeBSD ↔ Linux have swapped IO/OUT bit
- O_CLOEXEC differs between FreeBSD ↔ Linux
issue #4254
WARNING: BREAKS CONFIG COMPATIBILITY!
This commit changes the configuration interface of the NIC router in a way that
may break systems that use the component without proper adjustment!
How to adjust:
At each occurrence of the 'dns_server_from' attribute in a NIC router
configuration replace the attribute name with 'dns_config_from'. The attribute
value remains unaltered.
DETAILED DESCRIPTION
The new attribute name 'dns_config_from' reflects that also other aspects of
the DNS configuration of the denominated domain are used by the DHCP server
that holds the attribute. This commit is a preparation for forwarding also the
domain name (DHCP option 15) with the mechanism behind the attribute.
Ref #4246
Via a new configuration attribute, the user can decide whether the router
should answer dropped fragmented IPv4 with an ICMP "destination unreachable"
packet and, if so, which value the ICMP code field of this packet should have.
The default is that the router doesn't send such responses (silently dropping
fragmented IPv4). The behavior is tested by the 'nic_router_ipv4_fragm' test.
Fixes#4236
If the new attribute 'dropped_fragm_ipv4' of the <report> tag in the NIC router
config is set "yes", the router will report the number of packets that were
dropped per interface respectively domain because fragmented IPv4 is not
supported. The default is not to report the counter. The behavior is tested by
the 'nic_router_ipv4_fragm' test.
Ref #4236
The NIC router used to ignore the IPv4 header fields "More fragments" and
"Fragment offset" completely. Therefore higher-level protocols of fragmented
IPv4 were interpreted wrong because each fragment was considered a self-
standing packet, expecting, for instance UDP/TCP headers somewhere inside of
the UDP/TCP data field. Normally, such packets were dropped as soon as the
UDP/TCP checksum check failed because of the misinterpretation. However,
it was also possible for fragmented IPv4 to pass the router although normally
only partially.
IPv4 fragmentation support in the router would introduce some potential
security risks and is presumably not an easy endeavor. So, for now, we settled
on not supporting IPv4 fragmentation. With this commit, the router simply drops
all fragmented IPv4. This is reflected to the log for each fragment as "drop
packet (fragmented IPv4 not supported)" when 'verbose_packet_drop="yes"' is
configured.
The new test 'run/nic_router_ipv4_fragm' is an automated test for this
behavior. The test is added to the autopilot list.
Ref #4236
- remove redundant file system factory
- remove dead code block
The code was guarded by preprocessor directives checking whether the
contrib code define "_USE_MKFS" is 1. As "_USE_MKFS" is not set one
for our port of FAT, the code was never executed and can be removed.
- remove uneffective config attributes
Apparently, the former XML attributes to the plugin 'drive' and
'codepage' had no effect. I tested them in a scenario with the VFS
block server on a disk-image boot-module as back end. Regardless of
the 'drive' value, the block session label was always "0". Regardless
of the 'codepage' value, the FAT on the disk image succeeded to mount
when not using '--codepage' for 'mkfs.fat' and failed to mount when
using '--codepage' to specify a supported but foreign codepage for
'mkfs.fat' (e.g. "720").
Ref #4220
There was one global static constructor:
! namespace Fatfs { static Constructible<Platform> _platform; }
This caused applications that used the lib or the <fatfs> VFS plugin to end up
in an uncaught exception due to Genode::Component complaining that method
'construct' returned without executing pending static constructors if they
didn't call Genode::Env::exec_static_constructors().
As the use of Genode::Env::exec_static_constructors() is discouraged in Genode,
this commit rather moves the '_platform' object to the scope of the
initializing function and introduces a global static pointer to the object that
gets set by the initializing function. Although this prevents the exception, it
is, technically speaking even worse than the former solution as the new pointer
isn't checked for validity in contrast to the 'Constructible' object.
However, so far, I don't see a clean solution to this problem without the need
for Genode::Env::exec_static_constructors().
Fixes#4220
