mirror of
https://github.com/genodelabs/genode.git
synced 2025-02-02 17:21:13 +00:00
eba9c15746
The patch adjust the code of the base, base-<kernel>, and os repository.
To adapt existing components to fix violations of the best practices
suggested by "Effective C++" as reported by the -Weffc++ compiler
argument. The changes follow the patterns outlined below:
* A class with virtual functions can no longer publicly inherit base
classed without a vtable. The inherited object may either be moved
to a member variable, or inherited privately. The latter would be
used for classes that inherit 'List::Element' or 'Avl_node'. In order
to enable the 'List' and 'Avl_tree' to access the meta data, the
'List' must become a friend.
* Instead of adding a virtual destructor to abstract base classes,
we inherit the new 'Interface' class, which contains a virtual
destructor. This way, single-line abstract base classes can stay
as compact as they are now. The 'Interface' utility resides in
base/include/util/interface.h.
* With the new warnings enabled, all member variables must be explicitly
initialized. Basic types may be initialized with '='. All other types
are initialized with braces '{ ... }' or as class initializers. If
basic types and non-basic types appear in a row, it is nice to only
use the brace syntax (also for basic types) and align the braces.
* If a class contains pointers as members, it must now also provide a
copy constructor and assignment operator. In the most cases, one
would make them private, effectively disallowing the objects to be
copied. Unfortunately, this warning cannot be fixed be inheriting
our existing 'Noncopyable' class (the compiler fails to detect that
the inheriting class cannot be copied and still gives the error).
For now, we have to manually add declarations for both the copy
constructor and assignment operator as private class members. Those
declarations should be prepended with a comment like this:
/*
* Noncopyable
*/
Thread(Thread const &);
Thread &operator = (Thread const &);
In the future, we should revisit these places and try to replace
the pointers with references. In the presence of at least one
reference member, the compiler would no longer implicitly generate
a copy constructor. So we could remove the manual declaration.
Issue #465
The NIC bridge provides multiple sessions of the 'Nic' service while using a single 'Nic' session for forwarding requests. It implements a flavour of the Proxy-ARP protocol (rfc1027). That means it allocates a virtual MAC address for each client. Whenever a client sends a packet, NIC bridge changes the sender's MAC address to the one it memorized for the client. Moreover, it monitors DHCP packets, and tracks the IP addresses assigned to each of its clients. Whenever ARP packets come from the outside, NIC bridge will answer them with the corresponding MAC address. By adding a 'mac' attribute to the 'nic_bridge' config node: one can define the first MAC address from which the NIC bridge will allocate MACs for its clients. For example: ! <config mac="02:02:02:02:02:00"/> Note that the least relevant byte will be ignored. NIC bridge will use it for enumerating its clients, starting from 0. Normally, NIC bridge is expected to be used in scenarios where an DHCP server is available. However, there are situations where the use of static IPs for virtual NICs is useful. For example, when using the NIC bridge to create a virtual network between the lighttpd web server and the Arora web browser, both running as Genode processes without real network connectivity. The static IP can be configured per client of the NIC bridge using a '<policy>' node of the configuration. For example, the following policy assigns a static address to a client with the session label "lighttpd". !<start name="nic_bridge"> ! ... ! <config> ! <policy label_prefix="lighttpd" ip_addr="10.0.2.55"/> ! </config> !</start> Of course, the client needs to configure its TCP/IP stack to use the assigned IP address. This can be done via configuration arguments examined by the 'lwip_nic_dhcp' libc plugin. For the given example, the configuration for the lighttpd process would look as follows. !<start name="lighttpd"> ! <config> ! <interface ip_addr="10.0.2.55" ! netmask="255.255.255.0" ! gateway="10.0.2.1"/> ! </config> !</start>