{"action":"opened","issue":{"url":"https://api.github.com/repos/genodelabs/genode/issues/2246","repository_url":"https://api.github.com/repos/genodelabs/genode","labels_url":"https://api.github.com/repos/genodelabs/genode/issues/2246/labels{/name}","comments_url":"https://api.github.com/repos/genodelabs/genode/issues/2246/comments","events_url":"https://api.github.com/repos/genodelabs/genode/issues/2246/events","html_url":"https://github.com/genodelabs/genode/issues/2246","id":201933303,"number":2246,"title":"init: report state","user":{"login":"nfeske","id":1268399,"avatar_url":"https://avatars.githubusercontent.com/u/1268399?v=3","gravatar_id":"","url":"https://api.github.com/users/nfeske","html_url":"https://github.com/nfeske","followers_url":"https://api.github.com/users/nfeske/followers","following_url":"https://api.github.com/users/nfeske/following{/other_user}","gists_url":"https://api.github.com/users/nfeske/gists{/gist_id}","starred_url":"https://api.github.com/users/nfeske/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nfeske/subscriptions","organizations_url":"https://api.github.com/users/nfeske/orgs","repos_url":"https://api.github.com/users/nfeske/repos","events_url":"https://api.github.com/users/nfeske/events{/privacy}","received_events_url":"https://api.github.com/users/nfeske/received_events","type":"User","site_admin":false},"labels":[{"id":203356,"url":"https://api.github.com/repos/genodelabs/genode/labels/feature","name":"feature","color":"1b7921","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-01-19T18:04:21Z","updated_at":"2017-01-19T18:04:21Z","closed_at":null,"body":"For scenarios where init is used in a nested way, it would be nice to obtain information about the state of init's children. This will become particularly interesting if we allow the init's configuration to be changed dynamically. Thanks to the redesigned parent interface as introduced in Genode 16.11, all state within init is held explicitly, including all sessions with their arguments. Init could report this information to a `Report` session and thereby give the consumer of such reports a detailed picture of the running scenario.\r\n\r\nThe level of detail must be adjustable with respect to the included included information and the rate of generated reports. I suggest to introduce a `<report>` config node. If present, a new report is generated each time, init's state changes (e.g., if sessions are requested/established/closed).\r\n\r\nTo prevent the report processing from consuming too much CPU time in complex scenarios where init's state changes all the time, an attribute `rate_limit_ms` can be specified to limit the rate of reports to be produced to the specified amount of milliseconds.\r\n\r\nIn the most basic setting, the report will contain a list of children with their names and general state (running, waiting for a resource response, etc.) and the resource quotas assigned. Further details can be enabled via additional attributes:\r\n\r\n* `session_requests=\"yes\"` information about all sessions (including the session arguments and the session state) used by the children.\r\n* `session_responses=\"yes\"' information about all sessions that the child provides to other children.\r\n* `child_ram=\"yes\"` information about the child's respective RAM session (quota, avail), which may not be the same as the RAM assigned by init because of the trading of session quotas. This attribute is optional because this information is more expensive to obtain that the resource quotas assigned by init (which are locally known).\r\n\r\nFurthermore, the report may contain information about the state of init's RAM session by setting the attribute `init_ram=\"yes\"`."}}
{"actor":{"display_login":"nfeske"}}