I agree with Josef. I've actually been thinking about this issue myself. Here are my ideas for how we could solve the issue without too much difficulty: 1. Make init terminate all children and restart when the config is updated. (for nested init configurations; possibly already implemented) 2. Create servers to forward/virtualize services and to quietly reconnect (if possible) whenever they lose their connection to the service they forward. (The vfs server fills this role, though it would be nice for it to handle filesystem driver failure as smoothly as possible.) 3. Allow init to provide services from its children.
On Mon, Jan 11, 2016 at 2:08 PM, Josef Söntgen < josef.soentgen@...1...> wrote:
Hi everyone,
just before Norman finalizes the roadmap I want to make some remarks myself. It is always easy to point out single features or even applications that one might want to have in or use on Genode and those differ between people. So rather than providing my personal wishlist of features x y z I want to give some brief insight after using Genode on a daily basis for a few months (referring to a *slightly* modified system configuration based on the Turmvilla scenario):
It works incredibly well (stable and fast) for what it is configured, as long as you do not try anything fancy. You can interactively start and stop subsystems and change them at run-time. You can also change the configuration of several components, which makes the whole system usable and even quite fun to work with or rather on. But at its core, the system configuration is still static. You have to know beforehand which component provides which service and you have to route components (e.g. which hard disk should be used etc) accordingly. By all means, in some use cases that is a good thing but might be a limiting factor when considering, e.g., desktop computing.
Ideally, it would be nice if most of the configuration but the essential one could be done at run-time. Unfortunately, not all components in question support reporting their state or allow configuration changes at run-time — we definitely should improve that.
Therefore, identifying an essential core system configuration, that provides enough functionality to bootstrap a subsequent system might be reasonable. I know, such a configuration always depends on the use case at hand but still. For debugging purposes we currently depend on some kind of interface that provides us with the much needed LOG output. For better or worse not all machines provide such an interface and that might limit the application area of Genode — maybe we can come up with some neat component/configuration that gets rid of this dependency?
Relating to some points discussed earlier in this thread, the lack of hardware support is for me personally not such a big deal. At the end of the day it is either the vesa_fb_drv, intel_fb_drv or maybe even a mali_fb_drv that provides the Framebuffer service. What is more important at the moment is how the components are linked together. Also, w/o the help of the community focusing too much an supporting interesting hardware platforms will probably draw manpower off from more pressing tasks (I would love to ditch x86 for some “better” platform but I do not see that happing any time soon). On that account, I also do not see the current lack of appealing GUI agents as such an important site — than again I fancy Plan 9 and should probably not raise my voice on this topic anyway ;-)
So, in contrast to 2015 where among other things stability was the most prominent field of activity, 2016 should probably be the year where we try to make the most of the system, by providing means to ease the task of configuring and integrating a Genode based system.
Regards Josef
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main