c137c595c8
Avoid a runtime warning message since our backend does not provide such constructor functions yet. If a backend requires them, it should initiate their execution by itself within the backend init functions. In coherence with the size_guard idea, the remote_rom packets are are separated into a simple layer packet and a data packet. While basically only managing common control informations, the layer packet may carry any payload. The data packet, instead, manages the transmission of the actual ROM payload and can be attached to the layer packet. This simplifies the management of the notification packets UPDATE and SIGNAL since they do not contain fields like 'offset' or 'payload_size' anymore. Now, a single thread manages all incoming RPC calls, signals and (thus) network packets. This will hopefully make further synchronization enhancements a lot easier. Further changes: * Following data packets are identified as such by their offset instead of their packet type field. This simplifies the protocol. * reduced redundancy in the packet building code * rewrap lines with >79 columns * fix compiler warnings * split backend code * Remove a few unnecessary include and using directives. * In order to avoid global variables across modules, 'verbose' is a member variable now. Later, its value may be set via constructor. * The nested Rx class is merged with Backend_base. This way, we avoid unnecessary maintenance as long as we don't have a clear design for ROM multiplexing which may require the management of multiple IP addresses etc. * The HANDLER template argument is removed since client and server inherit from Backend_base anyway. The receive method is virtual now. * The signals packet_avail and ready_to_ack are directly passed to the same signal handler now. * Remove unnecessarily public/protected visibility from some members. * Remove and add unnecessary and, due to inclusion order, secretly missing include directives, respectively.
==========================================================
A collection of community-maintained components for Genode
==========================================================
This repository hosts Genode components that do not fall in the narrow scope of
the Genode OS Framework (http://genode.org), e.g., ported applications,
libraries, and games.
To use it, you first need to obtain a clone of Genode:
! git clone https://github.com/genodelabs/genode.git genode
Now, clone the _genode-world.git_ repository to _genode/repos/world_:
! git clone https://github.com/genodelabs/genode-world.git genode/repos/world
By placing the _world_ repository under the _repos/_ directory, Genode's tools
will automatically incorporate the ports provided by the _world_ repository.
For building software of the _world_ repository, the build-directory
configuration _etc/build.conf_ must be extended with the following line:
! REPOSITORIES += $(GENODE_DIR)/repos/world
Note of caution
---------------
In contrast to the components found in the mainline Genode repository, the
components within the _world_ repository are not subjected to the regular
quality-assurance measures of Genode Labs. Hence, problems are to be expected.
If you encounter bugs, build problems, or stability issues, please report them
to the issue tracker [1] or the Genode mailing list [2].
[1] https://github.com/genodelabs/genode-world/issues
[2] http://genode.org/community/mailing-lists