genode/repos/ports/run/noux_trace_fs.run

232 lines
5.9 KiB
Plaintext
Raw Normal View History

os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
#
# The Linux version of Noux lacks the support for the fork system call. Hence,
# the run script is expected to fail.
#
if {[have_spec linux]} {
puts "Linux is unsupported."
exit 0
}
proc gpio_drv { } { if {[have_spec rpi] && [have_spec hw]} { return hw_gpio_drv }
if {[have_spec rpi] && [have_spec foc]} { return foc_gpio_drv }
return gpio_drv }
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
#
# On OMAP4 where no PS/2 is available, we rely on USB HID
#
proc use_usb_input { } { return [expr ![have_spec ps2] && [have_spec usb]] }
#
# Uncomment the following line when working on the VIM source code. Otherwise,
# the package may get recompiled, yet it does not get reinstalled into 'bin/'.
#
#exec rm -rf noux-pkg/bash bin/bash
set build_components {
core init drivers/timer noux/minimal lib/libc_noux
drivers/framebuffer drivers/input
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
server/terminal server/ram_fs server/trace_fs
test/libports/ncurses
lib/trace/policy/rpc_name
}
lappend_if [use_usb_input] build_components drivers/usb
lappend_if [have_spec gpio] build_components drivers/gpio
set noux_pkgs "bash coreutils grep vim"
#
# Build Noux packages only once
#
foreach pkg $noux_pkgs {
lappend_if [expr ![file exists bin/$pkg]] build_components noux-pkg/$pkg }
source ${genode_dir}/repos/base/run/platform_drv.inc
append_platform_drv_build_components
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
build $build_components
create_boot_directory
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
# write default vimrc file
set vimrc_fd [open "bin/vimrc" w]
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
puts $vimrc_fd {
set noloadplugins
set hls
set nocompatible
set laststatus=2
set noswapfile
set viminfo=}
close $vimrc_fd
append config {
<config verbose="yes">
<parent-provides>
<service name="ROM"/>
<service name="LOG"/>
<service name="RM"/>
<service name="CPU"/>
<service name="PD"/>
<service name="IRQ"/>
<service name="IO_PORT"/>
<service name="IO_MEM"/>
<service name="TRACE"/>
</parent-provides>
<default-route>
<any-service> <parent/> <any-child/> </any-service>
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
</default-route>
<default caps="100"/>
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
<start name="timer">
<resource name="RAM" quantum="1M"/>
<provides><service name="Timer"/></provides>
</start> }
append_if [have_spec sdl] config {
<start name="fb_sdl">
<resource name="RAM" quantum="4M"/>
<provides>
<service name="Input"/>
<service name="Framebuffer"/>
</provides>
</start>}
append_platform_drv_config
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
append_if [have_spec framebuffer] config {
<start name="fb_drv" caps="200">
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
<resource name="RAM" quantum="4M"/>
<provides><service name="Framebuffer"/></provides>
<config width="640" height="480" />
</start>}
append_if [have_spec ps2] config {
<start name="ps2_drv">
<resource name="RAM" quantum="1M"/>
<provides><service name="Input"/></provides>
</start> }
append_if [have_spec gpio] config "
<start name=\"[gpio_drv]\">
<resource name=\"RAM\" quantum=\"4M\"/>
<provides><service name=\"Gpio\"/></provides>
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
<config/>
</start>"
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
append_if [use_usb_input] config {
<start name="usb_drv">
<resource name="RAM" quantum="12M"/>
<provides><service name="Input"/></provides>
<config uhci="yes" ehci="yes" xhci="yes"> <hid/> </config>
</start> }
append config {
<start name="terminal">
<resource name="RAM" quantum="2M"/>
<provides><service name="Terminal"/></provides>
<config>
<keyboard layout="us"/>
<font size="12" />
</config>
</start>
<start name="trace_fs">
<resource name="RAM" quantum="128M"/>
<provides><service name="File_system"/></provides>
<config>
<policy label="noux -> trace" root="/" interval="1000" subject_limit="512" trace_quota="64M" parent_levels="0" />
</config>
</start>
<start name="ram_fs">
<resource name="RAM" quantum="32M"/>
<provides><service name="File_system"/></provides>
<config>
<content>
<dir name="home">
<inline name=".bash_profile">
</inline>
</dir>
<dir name="tmp">
<dir name="policies">
<rom name="rpc_name" />
</dir>
</dir>
</content>
<!-- constrain sessions according to their labels -->
<policy label="noux -> root" root="/" />
<policy label="noux -> home" root="/home" writeable="yes" />
<policy label="noux -> tmp" root="/tmp" writeable="yes" />
</config>
</start>
<start name="noux" caps="200">
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
<resource name="RAM" quantum="256M" />
<config>
<fstab> }
foreach pkg $noux_pkgs {
append config " <tar name=\"$pkg.tar\" />" }
append config {
<dir name="home"> <fs label="home" /> </dir>
<dir name="ram"> <fs label="root" /> </dir>
<dir name="tmp"> <fs label="tmp" /> </dir>
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
<dir name="trace"> <fs label="trace" /> </dir>
<dir name="dev">
<null /> <zero />
</dir>
<dir name="share"> <dir name="vim"> <rom name="vimrc"/> </dir> </dir>
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
</fstab>
<start name="/bin/bash">
<env name="TERM" value="screen" />
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
<env name="HOME" value="/home" />
<arg value="--login" />
</start>
</config>
<route>
<service name="File_system" label="home">
<child name="ram_fs" /> </service>
<service name="File_system" label="root">
<child name="ram_fs" /> </service>
<service name="File_system" label="tmp">
<child name="ram_fs" /> </service>
<service name="File_system" label="trace">
<child name="trace_fs"/> </service>
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
<any-service> <parent /> <any-child /> </any-service>
</route>
</start>
</config>}
install_config $config
#
# Boot modules
#
# generic modules
set boot_modules {
core init timer ld.lib.so noux terminal ram_fs
libc.lib.so libm.lib.so libc_noux.lib.so posix.lib.so
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
ncurses.lib.so pcre.lib.so zlib.lib.so readline.lib.so
trace_fs
rpc_name
}
foreach pkg $noux_pkgs {
append boot_modules " $pkg.tar " }
# platform-specific modules
lappend_if [have_spec linux] boot_modules fb_sdl
lappend_if [have_spec ps2] boot_modules ps2_drv
lappend_if [have_spec framebuffer] boot_modules fb_drv
lappend_if [use_usb_input ] boot_modules usb_drv
lappend_if [have_spec gpio] boot_modules [gpio_drv]
append_platform_drv_boot_modules
os: initial version of trace_fs The trace_fs server provides access to a Trace_session by using a File_system_session as frontend. Each trace subject is represented by a directory ('thread_name.subject') that contains specific files ('active', 'cleanup', 'enable', 'events', 'buffer_size' and 'policy'), which are used to control the tracing process of the thread as well as storing the content of its trace buffer. The tracing of a thread is only activated if there is a valid policy installed and the intend to trace the subject was made clear by writing '1' to the 'enable' file. The tracing of a thread may be deactived by writing a '0' to the 'enable' file. A policy may be changed by overwriting the currently used one. In this case the old policy is replaced by the new policy and is automatically utilize. Writing a value to the 'buffer_size' file changes the appointed size of the trace buffer. This value is only evaluted by reactivating the tracing process. The content of the trace buffer may be accessed by reading from the 'events' file. Throughout all tracing session new trace events are appended to this file. Nodes of UNTRACED subjects are kept as long as they do not change their tracing state to DEAD. In this case all nodes are removed from the file system. Subjects that were traced before and are now UNTRACED will only be removed by writing '1' to the 'cleanup' file - even if they are DEAD by now. To use the trace_fs a config similar to the following may be used: ! <start name="trace_fs"> ! <resource name="RAM" quantum="128M"/> ! <provides><service name="File_system"/></provides> ! <config> ! <policy label="noux -> trace" interval="1000" subject_limit="512" trace_quota="64M" /> ! </config> ! </start> 'interval' sets the periode in which the Trace_session is polled. The time is given in milliseconds. 'subject_limit' speficies how many trace subject should by acquired at most when the Trace_session is polled. 'trace_quota' is the amount of quota the trace_fs should use for the Trace_session connection. The remaing amount of RAM quota will be used for the actual nodes of the file system and the 'policy' as well as the 'events' files. In addiition there are 'buffer_size' and 'buffer_size_limit' that define the initial and the upper limit of the size of a trace buffer. Tracing of parent processes or rather threads may be enabled by setting 'parent_levels' to a value greater than '0' (though this attribute is available, the trace session component within core still lacks support for it). A ready-to-use runscript can by found in 'ports/run/noux_trace_fs.run'. Fixes #1049.
2014-01-17 15:04:04 +00:00
build_boot_image $boot_modules
run_genode_until forever
# vi: set ft=tcl :