Hi Charles, > My use case is a dynamic system with centralized resource management and > control. I'd like to be able to instantiate specific-purpose subsystems > isolated from each other and from the resource manager. When a subsystem > is created, its launcher has to bargain with the manager (through the > loader and a modified loader session) to obtain resources. It's a sort > of fusion between the cli_monitor and the loader. The subsystems should > however be able to yield back resources when, for example, one of their > children exits.
thank you for providing more details. I am actually thinking in a very similar direction: Like you, I want to manage subsystems dynamically but don't want to implement the (potentially complex) management component as the parent of the managed subsystems. My current idea is to enhance init so that it will be able to respond to configuration changes in a sensible way. Right now, init replaces all children with new instances each time when its configuration changes. In the future, I plan to let init apply only the actual configuration changes. E.g., killing the subsystems that disappeared in the new config, starting new subsystems for new appearing <start> nodes, adjusting the resource assignments, or propagating changes in the subsystem's respective <config> nodes. Furthermore, init would produce reports about the state of the running subsystems, the RAM usage, etc. BTW, as far as I know, Johannes Schlatow already implemented a prototype of this approach. With the new (dynamic) version of init in place, CLI monitor would not manage subsystems as its children any longer. It would merely generate configurations for an instance of init that can live somewhere else in the component tree. Alternatively to using CLI monitor, system scenarios could be interactively modified on-the-fly by editing the config of a dynamic init via Vim running inside Noux. Wouldn't that be cool? :-) I wonder, would this principle design satisfy your use case, too? > As a side question, how is the quota associated with a session > registered? Is every component involved in the session creation > responsible for remembering the quota it transfered? Yes. The common parent of the client and server keeps those records. This is natural because the common parent actually owns both client and server and deliberately moves resource budgets between them. The resource trading solely happens along the branches of the component tree. Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main