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
|
|
|
build "core init test/dynamic_config"
|
|
|
|
|
|
|
|
create_boot_directory
|
|
|
|
|
|
|
|
install_config {
|
|
|
|
<config>
|
|
|
|
<parent-provides>
|
|
|
|
<service name="ROM"/>
|
|
|
|
<service name="CPU"/>
|
|
|
|
<service name="RM"/>
|
|
|
|
<service name="PD"/>
|
|
|
|
<service name="IRQ"/>
|
|
|
|
<service name="IO_PORT"/>
|
|
|
|
<service name="LOG"/>
|
|
|
|
</parent-provides>
|
|
|
|
<default-route>
|
|
|
|
<any-service> <parent/> <any-child/> </any-service>
|
|
|
|
</default-route>
|
|
|
|
<start name="timer">
|
|
|
|
<resource name="RAM" quantum="1M"/>
|
|
|
|
<provides><service name="Timer"/></provides>
|
|
|
|
</start>
|
|
|
|
<start name="test-dynamic_config_master">
|
|
|
|
<resource name="RAM" quantum="2M"/>
|
|
|
|
</start>
|
|
|
|
</config>
|
|
|
|
}
|
|
|
|
|
2016-12-01 18:00:11 +00:00
|
|
|
build_boot_image "core ld.lib.so init timer test-dynamic_config test-dynamic_config_master"
|
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
|
|
|
|
2017-05-23 13:05:55 +00:00
|
|
|
append qemu_args "-nographic "
|
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
|
|
|
|
|
|
|
run_genode_until {obtained counter value 11 from config.*} 100
|
|
|
|
|
|
|
|
puts "Test succeeded"
|