genode/repos/os/src/server/trace_fs/followed_subject.h

284 lines
6.1 KiB
C
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
/*
* \brief Facility for managing the trace subjects
* \author Josef Soentgen
* \date 2014-01-22
*/
/*
* Copyright (C) 2014-2017 Genode Labs GmbH
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
*
* This file is part of the Genode OS framework, which is distributed
* under the terms of the GNU Affero General Public License version 3.
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
*/
#ifndef _SUBJECT_REGISTRY_H_
#define _SUBJECT_REGISTRY_H_
#include <base/allocator.h>
#include <base/lock.h>
#include <base/trace/types.h>
#include <directory.h>
#include <trace_files.h>
namespace Trace_fs {
typedef Genode::size_t size_t;
class Followed_subject;
class Followed_subject_registry;
}
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
class Trace_fs::Followed_subject : public Directory
{
public:
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
/**
* This class manages the access to the trace subject's trace buffer
*/
class Trace_buffer_manager
{
public:
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
class Already_managed { };
class Not_managed { };
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
struct Process_entry
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
{
virtual size_t operator()(Genode::Trace::Buffer::Entry&) = 0;
};
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
private:
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
Genode::Trace::Buffer *buffer;
Genode::Trace::Buffer::Entry current_entry;
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
public:
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
Trace_buffer_manager(Genode::Region_map &rm,
Genode::Dataspace_capability ds_cap)
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
:
buffer(rm.attach(ds_cap)),
current_entry(buffer->first())
{ }
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
size_t dump_entry(Process_entry &process)
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
{
size_t len = process(current_entry);
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
current_entry = buffer->next(current_entry);
return len;
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
}
bool last_entry() const
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
{
return current_entry.last();
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
}
void rewind() { current_entry = buffer->first(); }
};
private:
Genode::Allocator &_md_alloc;
Genode::Region_map &_rm;
int _handle;
Genode::Trace::Subject_id _id;
Genode::Trace::Policy_id _policy_id;
bool _was_traced;
Trace_buffer_manager *_buffer_manager;
public:
Active_file active_file;
Buffer_size_file buffer_size_file;
Cleanup_file cleanup_file;
Enable_file enable_file;
Events_file events_file;
Policy_file policy_file;
Followed_subject(Genode::Allocator &md_alloc, char const *name,
Genode::Region_map &rm,
Genode::Trace::Subject_id &id, int handle)
:
Directory(name),
_md_alloc(md_alloc),
_rm(rm),
_handle(handle),
_id(id),
_was_traced(false),
_buffer_manager(0),
active_file(_id),
buffer_size_file(),
cleanup_file(_id),
enable_file(_id),
events_file(_id, _md_alloc),
policy_file(_id, _md_alloc)
{
adopt_unsynchronized(&active_file);
adopt_unsynchronized(&cleanup_file);
adopt_unsynchronized(&enable_file);
adopt_unsynchronized(&events_file);
adopt_unsynchronized(&buffer_size_file);
adopt_unsynchronized(&policy_file);
}
~Followed_subject()
{
discard_unsynchronized(&active_file);
discard_unsynchronized(&cleanup_file);
discard_unsynchronized(&enable_file);
discard_unsynchronized(&events_file);
discard_unsynchronized(&buffer_size_file);
discard_unsynchronized(&policy_file);
}
bool marked_for_cleanup() const { return cleanup_file.cleanup(); }
bool was_traced() const { return _was_traced; }
Trace_buffer_manager* trace_buffer_manager() { return _buffer_manager; }
void manage_trace_buffer(Genode::Dataspace_capability ds_cap)
{
if (_buffer_manager != 0)
throw Trace_buffer_manager::Already_managed();
_buffer_manager = new (&_md_alloc) Trace_buffer_manager(_rm, ds_cap);
}
void unmanage_trace_buffer()
{
if (_buffer_manager == 0)
throw Trace_buffer_manager::Not_managed();
destroy(&_md_alloc, _buffer_manager);
_buffer_manager = 0;
}
const Genode::Trace::Subject_id id() const { return _id; }
const Genode::Trace::Policy_id policy_id() const { return _policy_id; }
void policy_id(Genode::Trace::Policy_id &id) { _policy_id.id = id.id; }
bool policy_valid() const { return (_policy_id.id != 0); }
void invalidate_policy() { _policy_id = Genode::Trace::Policy_id(); }
int handle() const { return _handle; }
};
/**
* This registry contains all current followed trace subjects
*/
class Trace_fs::Followed_subject_registry
{
public:
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
class Invalid_subject { };
class Out_of_subject_handles { };
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
private:
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
/* XXX abitrary limit - needs to be revisited when highly
* dynamic scenarios are executed */
enum { MAX_SUBJECTS = 1024U };
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
Followed_subject *_subjects[MAX_SUBJECTS];
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
Genode::Allocator &_md_alloc;
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
/**
* Find free subject handle
*
* \throw Out_of_subject_handles
*/
int _find_free_handle()
{
for (unsigned i = 0; i < MAX_SUBJECTS; i++)
if (!_subjects[i]) {
return i;
}
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
throw Out_of_subject_handles();
}
bool _in_range(int handle) const
{
return ((handle >= 0) && (handle < MAX_SUBJECTS));
}
public:
Followed_subject_registry(Genode::Allocator &md_alloc)
:
_md_alloc(md_alloc)
{
for (unsigned i = 0; i < MAX_SUBJECTS; i++)
_subjects[i] = 0;
}
/**
* Return maximal number of subject that can be stored in the registry
*
* \return maximal number of subjects
*/
unsigned max_subjects() const { return MAX_SUBJECTS; }
/**
* Allocate new subject
*
* \param name name of subject
* \param id subject id of tracre subject
*/
Followed_subject *alloc(char const *name, Genode::Trace::Subject_id &id,
Genode::Region_map &rm)
{
int handle = _find_free_handle();
_subjects[handle] = new (&_md_alloc) Followed_subject(_md_alloc, name, rm, id, handle);
return _subjects[handle];
}
/**
* Free subject
*
* \param subject pointer to subject
*/
void free(Followed_subject *subject)
{
int handle = subject->handle();
if (!_in_range(handle))
return;
if(!_subjects[handle])
return;
_subjects[handle] = 0;
destroy(&_md_alloc, subject);
}
/**
* Lookup subject by using the id
*
* \throw Invalid_subject();
*/
Followed_subject *lookup(Genode::Trace::Subject_id const &sid)
{
for (unsigned i = 0; i < MAX_SUBJECTS; i++)
if (_subjects[i]) {
if (_subjects[i]->id().id == sid.id)
return _subjects[i];
}
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
throw Invalid_subject();
}
};
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
#endif /* _SUBJECT_REGISTRY_H_ */