This commit changes the touch-click filter to adhere the following
sequence:
touch (physical)
press (artifically generated)
release (artificially generated)
release_touch (physical)
This order is important because nitpicker's focus handling takes
press/release events into account. If the release-touch event appears
before the release event, nitpicker subsumes the release-touch event
to the sequence that started with the press event, instead of handling
it as a free-standing event.
Issue #4332
This patch makes nitpicker's "clicked" report useful for the detection
of clicks outside of any client. This is needed in situations where the
dialog should close when clicking outside its screen area. In the new
version, a click outside any client results in a report without a
'label' attribute. Furthermore, the report is augmented by the sequence
number of the click, which allows for freshness checks by the consumer of
the report (i.e., sculpt_manager).
Issue #4398
This patch replaces formerly blocking packet-stream operations by
the explicit use of 'wait_and_dispatch_io_signal' for blocking.
It also removes a misleading comment that promised a fire-and-forget
behavior whereas the implementation relied on blocking I/O anyway.
Issue #4390
Remove '_expected_offset' check on round trip test from RX packet,
because allocators between RX/TX can have different allocation
strategies. Rely on 'pattern' check for RX packets only.
In loopback server alloc size must match actual packet size.
issue #4312
Pre-allocate all possible type of policy objects as part of the thread meta
state to avoid increased memory consumption due to different policy object
sizes. The cpu_balancer accounts the memory per client and can't forward
potentially occurring out-of-ram exceptions during config-ROM update phases.
Fixes#4333
The commits avoids reading in and allocating memory for all potentially
threads, which are potentially currently not existent (but configured in the
policy beforehand). Instead the policy is read in and evaluated when a thread
is created and policy changes are solely applied to existing/running threads.
By this the commit avoids the increase of memory consumption during the
evaluation of policies during config ROM updates.
Issue #4333
This filter bridges the gap between a touchscreen driver, which
generates raw touch events and traditional GUI applications that expect
a pointer (absolute motion, press/release of the left mouse button).
Fixes#4332
This patch changes the 'Allocator' interface to the use of 'Attempt'
return values instead of using exceptions for propagating errors.
To largely uphold compatibility with components using the original
exception-based interface - in particluar use cases where an 'Allocator'
is passed to the 'new' operator - the traditional 'alloc' is still
supported. But it existes merely as a wrapper around the new
'try_alloc'.
Issue #4324
Since the top-level node of the output ROM is always generated by the
rom_filter, there is no way to pass-through the content of an input ROM
without wrapping in an addition XML node.
genodelabs/genode#4326
This patch replaces the 'Ram_allocator::alloc' RPC function by a
'try_alloc' function, which reflects errors as 'Attempt' return value
instead of an exception.
Issue #4322
Issue #3612
This patch extends the notion of having only one uniquely hovered client
in the presence of held keys.
If motion occurs once a key is pressed (e.g., while dragging), the
receiver of the key sequence observes the motion events. In this case,
we have to submit an artificial leave event to the originally hovered
client so that no more than one client observes itself as being hovered
at the same time. Once the key sequence is finished, the hovering is
updated again, eventually presenting a motion event to the originally
hovered client and a leave event to the receiver of the key sequence.
Issue #4176
The former implementation did not internally track ROM changes notified
vs. delivered to the client. We adapt the versioning implementation
implemented in dynamic_rom_session.h and enable explicit notification of
the current version.
The feature is used by the clipboard to notify permitted readers of the
clipboard ROM service on focus change via the newly created private
Rom::Module::_notify_permitted_readers() function.
Fixes#4274
The NIC router parses, stores and forwards DNS domain names from DHCP replies.
Yet the routers DHCP client used to not request DNS domain-name information on
DHCP requests. This caused DHCP servers to skip this information on their
replies although it was available. This commit fixes the issue by adding the
DNS domain name code to the request parameter list of requests from the routers
DHCP client.
The 'black_hole' component provides dummy implementations of common
session interfaces.
At this time, only the 'Audio_out' session is provided if enabled
in the configuration of the component:
<config>
<audio_out/>
</config>
Issue #3653
With this commit, the NIC router DHCP client reads out the first DNS domain
name (DHCP option 15) if any from a DHCP reply that generates an IPv4 config
for a domain and stores the name together with the IPv4 config for that domain.
DNS domain names are reported via the new report tag '<dns-domain>' if the
'config' attribute in the config tag '<report>' is set.
Furthermore, the NIC router DHCP server becomes able to obtain a DNS domain
name from another domain that has a DHCP client dynamically (given the config
attribute 'dns_config_from' is set and no static DNS config is given) or
statically from its configuration (new config tag '<dns-domain>') and propagate
this name with DHCP replies (DHCP option 15).
The 'nic_router_dhcp_*' tests are adapted to test the new feautures.
The commit also gets rid of some mirrored files in
'test/nic_router_dhcp/manager'.
Fixes#4246
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
The fact that the IPv4 config was a struct with all data members public was a
mere leftover of an early state of the NIC router. Today, the router
implementation style is to avoid structs and public data members wherever
possible.
This commit slightly changes the behavior of the router regarding log output.
The router used to print malformed IPv4 configurations to the log only if
the 'verbose' config flag was set using this style:
! [my_domain] malformed dynamic IP config: interface 10.0.2.1/24 ...
Now, malformed IPv4 configurations are only printed if the
'verbose_domain_state' config flag is set (like with any IP4v configuration
states) using this style:
! [my_domain] dynamic IP config: malformed (interface 10.0.2.1/24 ...)
Fixes#4242
The NIC router DHCP server used to add an extra option 6 field to DHCP replies
for each DNS server address. This conflicts with RFC #2132 section 3.8 which
states that the addresses should be listed within one option 6 field without
delimiter. The discrepancy is fixed by this commit.
Ref #4242
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
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
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
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
When Interface::handle_config_3 (third step of applying a new configuration to
interfaces) tried to detach the interface from the current IP config because
the old and new IP config differed, it did so using the new domain. The former
steps of the reconfiguration already installed the new domain reference at the
interface. Therefore, also the DHCP server of the new domain was used. This,
however caused uncaught exceptions because detaching from an IP config
includes dissolving all DHCP allocations. This dissolving of DHCP allocations
now operated on a DHCP server (the one of the new domain) that wasn't related
to the allocations and, in the worst case, caused an uncaught exception
because the IPs were out of its range.
That said, this commit ensures that detaching an interface from an IP config
is always done on the domain from which the IP config originated. Normally,
this is the domain the interface is attached to. But in the case of
Interface::handle_config_3, it is another - the former domain the interface
was attached to.
The commit also adapts the nic_router_dhcp_* tests in a way that they
reconfigure the router in a way that would trigger the uncaught exception
without the fix.
Fixes#4200
Enable watching files via the inotify interface of the Linux Kernel.
Delivery of watches to components is staggered in order to prevent an
overflow of the ACK queue in cases when a lot of changes are made to the
file system from the Linux side.
Fixes#4070
