- 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
* the GPU multiplexer now offers the platform service to the Intel
framebuffer driver (driver_manager)
* ajdusted drivers_managed-pc to hand out resources to the GPU driver
* adjust quotas
issue #4233
The platform services is intented to be used by dde_linux's intel_fb_drv
in order to initlialize displays.
* implement and announce platform session
* limit accessible GTT and aperture of client to 64 MB
* forward display engine IRQs to platform client
* move all PCI resources to 'Igd::Resources' class in order to make them
accessible by the platform service and the GPU driver
* fix fence register allocation for id zero (return true)
issue #4233
For mesa-21 the client takes care and manages
the virtual address space of the vGPU by itself and the intel/gpu driver
can't add silently a guard page anymore. Move the patch to the drm/ioctl
of the former mesa version.
Issue #4148#4233
_unmap_dataspace_ggtt requires the cap of Ggtt::Mapping (ring_map, ctx_map)
in order to find the right metadata and to free up the ggtt entries. Also the
pte range is removed already if the metadata was found.
Issue #4148#4233
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 '<uplink ...>' tag in a NIC router configuration
replace the tag name 'uplink' with 'nic-client'. The rest of the tag stays the
same.
The term "uplink" for network interfaces in the router that have a NIC session
client as back end was introduced in a time when Uplink sessions didn't yet
exist. Now, they do and, although both an uplink and an Uplink session
normally describe a network session between router and network device driver,
they are based on two different service types (NIC and Uplink). This can easily
cause confusion when integrating the router (the <uplink> is not related to
Uplink sessions) or trying to understand its functioning (an 'Uplink' object
has nothing to do with the Uplink service).
Therefore, this commit introduces the more specific term "NIC client" for an
interface that is based on a NIC session requested by the router. This doesn't
imply any semantic changes at the NIC router. However, the commit also brings a
broader update of the router's README and removes the term "downlink" that was
used only in documentation to refer to interfaces backed by a NIC session
provided by the router. The term was only associated with this meaning because
it is the natural counterpart to an uplink. This isn't appropriate anymore as
the terms for interface types have moved to a more technical level.
The commit adjusts all scenarios in the basic Genode repositories properly.
Fixes#4238
An interface that received a signal for a link-state change accessed its
domain reference without assuming that it could not be attached to a domain
at that moment. This caused the NIC router to crash with an uncaught exception
of type 'Net::Pointer<Net::Domain>::Invalid'. The commit adds a catch
directive for this exception resulting in the handler doing nothing if not
attached to any domain.
Fixes#4222
The test script failed during preparation of the on-target execution for
USB Armory with the following error:
! can't read "tz_vmm_block_irq": no such variable
Presumably, the script wasn't run anymore since the introduction of the
'tz_vmm_block_irq' variable for i.MX53 QSB. As we do not have infrastructure
for automated testing of the USB Armory and there seems to be not much
interest in using Genode on this platform, this commit simply removes the
support from the script.
Filtering boards in a run script by specs isn't the right way anymore (the
specs do not exist anymore). Nowadays, we have to use [have_board] instead.
Ref #4229
For unknown reasons, the former 'wget genode.org' call, that was meant to test
network in the Trustzone guest on imx53_qsb_tz, didn't succeed anymore although
the same call succeeded on my Sculpt VM Linux. However, 'ping 1.1.1.1' still
works, so, the script now uses this as test for networking instead.
Fixes#4229
So far, in order to create an ARP reply, the NIC router merely created a copy
of the corresponding ARP request and modified only those values that differ.
This approach has the disadvantage of re-using bad parameters from a broken
request. The specific use-case that made this visible was an early version of
the Pine board network driver that used to forward ARP requests with a greater
size than required. The ARP replies of the router re-used this size and
confused other network nodes with that. In general, the NIC router should
rely on the data of incoming packets the least possible. Therefore, with this
commit, the router creates a new ARP reply from scratch and uses only those
values required from the corresponding ARP request.
Fixes#4235
The former declaration of the IPv4 packet did not only use the questionable
tool of implementation-defined C++ bitsets but also lacked access to flags
"don't fragment" (DF) and "more fragments" (MF). This commit replaces the
C++ bitsets by using the register framework and introduces accessors for the
missing flags.
Ref #4236
This commit introduces a C-API to the Uplink session, as well as to
serve as a Block service. It can be used by drivers ported from
C-only projects, like the Linux kernel, or BSD kernels for instance.
Fix#4226
The re-newed approach currently supports ARM 64-bit only.
It depends on the Platform API of the ARM architecture.
It tries to meet the original semantic of the Linux kernel
functions as far as possible. To achieve this, device drivers
using this library should reference the original Linux kernel
headers at foremost. Only the headers in `src/include/lx_emul/shadow`
have to shadow clone the original ones.
Fix#4225
skb_push() already increases the skb->len by ETH_HLEN, hence adding
ETH_HLEN to the packet_size is redundant.
A too large packet size becomes a problem for large MTUs. With a maximum
MTU of 1500, adding ETH_HLEN twice will lead to a packet size of 1528.
Since this is larger than what we expect for good-old Ethernet (max. 1522),
some clients (e.g. the e1000 model in vbox5) may drop these packets.
Fixesgenodelabs/genode#4228
I discovered thinkbroadband.com requires the User-Agent header field and
rejects requests missing it with HTTP response code 403 "access to the
requested resource is forbidden". Now, fetchurl always adds the
User-Agent header fetchurl/LIBCURL_VERSION.
Also the error message now contains the HTTP response code.
The symlink implementation wrongly constructed a 'Sync' object within
the context of a monitor call. The 'Sync' constructor indirectly
depended on libc I/O for obtaining the current time, ultimately
resulting in a nested attempt of a monitor call. This could be
reproduced via the base.run script:
$ cd /home
$ ln -s a b
The 'ln' command resulted in the following log message:
[init -> /bin/bash -> 7] Error: deadlock ahead, mutex=0x10ff8c70, return ip=0x500583a7
The patch fixes the problem by splitting the single monitor call into
two monitor calls and moving the construction of the 'Sync' object
in-between both monitor calls, thereby executing the constructor at the
libc application level.
Fixes#4219
Building the elfloader in kernel-sel4.inc has a problem with Genodes CCACHE
make variable. When issuing ...
! ./tool/depot/create mstein/bin/*/base-sel4-* CCACHE=yes
..., building the elfloader used to consume all memory of the host system and
then run into a segmentation fault:
! make[6]: *** [elfloader/elfloader.o] Segmentation fault (core dumped)
This is because the other build system invokes the CCACHE variable as a command
in front of the compiler command. If CCACHE is set to 'yes', the 'yes' command
is called and produces an endless output into some output file. The problem
can be fixed by locally re-setting the CCACHE variable for the
'make ... elfloader' command to 'ccache' (Genode CCACHE==yes) or '' (Genode
CCACHE!=yes).
Fixes#4212
Adds try-catch-statement with diagnostic errors in Dhcp_server::free_ip in
order to guard against exceptions from the underlying bit allocator. These
exceptions should never happen given that the router is programmed correctly
and always feeds Dhcp_server::free_ip with sane arguments (which it should).
However, should this not be the case, we can assume that the failed IP freeing
indicates that the IP isn't allocated anyway and it's fine to continue using
the router. Furthermore, IP allocations are a mere client service and not
relevant for the integrity or safety of the router.
Ref #4200
