genode/repos/base/include/rom_session/rom_session.h

112 lines
3.5 KiB
C
Raw Normal View History

2011-12-22 15:19:25 +00:00
/*
* \brief ROM session interface
* \author Norman Feske
* \date 2006-07-06
*
* A ROM session corresponds to a ROM module. The module name is specified as
* an argument on session creation.
2011-12-22 15:19:25 +00:00
*/
/*
* Copyright (C) 2006-2014 Genode Labs GmbH
2011-12-22 15:19:25 +00:00
*
* This file is part of the Genode OS framework, which is distributed
* under the terms of the GNU General Public License version 2.
*/
#ifndef _INCLUDE__ROM_SESSION__ROM_SESSION_H_
#define _INCLUDE__ROM_SESSION__ROM_SESSION_H_
#include <dataspace/capability.h>
#include <session/session.h>
Support for dynamic ROM sessions, fix #170 This patch introduces support for ROM sessions that update their provided data during the lifetime of the session. The 'Rom_session' interface had been extended with the new 'release()' and 'sigh()' functions, which are needed to support the new protocol. All ROM services have been updated to the new interface. Furthermore, the patch changes the child policy of init with regard to the handling of configuration files. The 'Init::Child' used to always provide the ROM dataspace with the child's config file via a locally implemented ROM service. However, for dynamic ROM sessions, we need to establish a session to the real supplier of the ROM data. This is achieved by using a new 'Child_policy_redirect_rom_file' policy to handle the 'configfile' rather than handling the 'configfile' case entirely within 'Child_config'. To see the new facility in action, the new 'os/run/dynamic_config.run' script provides a simple scenario. The config file of the test program is provided by a service, which generates and updates the config data at regular intervals. In addition, new support has been added to let slaves use dynamic reconfiguration. By using the new 'Child_policy_dynamic_rom_file', the configuration of a slave can be changed dynamically at runtime via the new 'configure()' function. The config is provided as plain null-terminated string (instead of a dataspace capability) because we need to buffer the config data anyway. So there is no benefit of using a dataspace. For buffering configuration data, a 'Ram_session' must be supplied. If no 'Ram_session' is specified at construction time of a 'Slave_policy', no config is supplied to the slave (which is still a common case). An example for dynamically reconfiguring a slave is provided by 'os/run/dynamic_config_slave.run'.
2012-04-04 15:07:19 +00:00
#include <base/signal.h>
2011-12-22 15:19:25 +00:00
namespace Genode {
struct Rom_dataspace;
struct Rom_session;
struct Rom_session_client;
2011-12-22 15:19:25 +00:00
typedef Capability<Rom_dataspace> Rom_dataspace_capability;
2011-12-22 15:19:25 +00:00
}
struct Genode::Rom_dataspace : Dataspace { };
struct Genode::Rom_session : Session
{
static const char *service_name() { return "ROM"; }
typedef Rom_session_client Client;
virtual ~Rom_session() { }
/**
* Request dataspace containing the ROM session data
*
* \return capability to ROM dataspace
*
* The capability may be invalid.
*
* Consecutive calls of this method are not guaranteed to return the
* same dataspace as dynamic ROM sessions may update the ROM data
* during the lifetime of the session. When calling the method, the
* server may destroy the old dataspace and replace it with a new one
* containing the updated data. Hence, prior calling this method, the
* client should make sure to detach the previously requested dataspace
* from its local address space.
*/
virtual Rom_dataspace_capability dataspace() = 0;
/**
* Update ROM dataspace content
*
* This method is an optimization for use cases where ROM dataspaces
* are updated at a high rate. In such cases, requesting a new
* dataspace for each update induces a large overhead because
* memory mappings must be revoked and updated (e.g., handling the
* page faults referring to the dataspace). If the updated content
* fits in the existing dataspace, those costly operations can be
* omitted.
*
* When this method is called, the server may replace the dataspace
* content with new data.
*
* \return true if the existing dataspace contains up-to-date content,
* or false if a new dataspace must be requested via the
* 'dataspace' method
*/
virtual bool update() { return false; }
/**
* Register signal handler to be notified of ROM data changes
*
* The ROM session interface allows for the implementation of ROM
* services that dynamically update the data exported as ROM dataspace
* during the lifetime of the session. This is useful in scenarios
* where this data is generated rather than originating from a static
* file, for example to update a program's configuration at runtime.
*
* By installing a signal handler using the 'sigh()' method, the
* client will receive a notification each time the data changes at the
* server. From the client's perspective, the original data contained
* in the currently used dataspace remains unchanged until the client
* calls 'dataspace()' the next time.
*/
virtual void sigh(Signal_context_capability sigh) = 0;
/*********************
** RPC declaration **
*********************/
GENODE_RPC(Rpc_dataspace, Rom_dataspace_capability, dataspace);
GENODE_RPC(Rpc_sigh, void, sigh, Signal_context_capability);
GENODE_RPC(Rpc_update, bool, update);
GENODE_RPC_INTERFACE(Rpc_dataspace, Rpc_update, Rpc_sigh);
};
2011-12-22 15:19:25 +00:00
#endif /* _INCLUDE__ROM_SESSION__ROM_SESSION_H_ */