Hi,
i would propose something quite boring:
Automated tests of each component and script and giving the results on a web page so one can easily see if everything is up and running together with an update of the documentation.
Why?
As I tried out genode I ran in a few issues. Some needed a fix from your site, some are never fixed (e.g. last problems between blkcache and rumpfs, last mail form Stefen Kalkowski with :" Well, I've tested the scenario on a "real" ext2 partition too, and observed the corruption of the filesystem with and without the blk_cache. Therefore, I assume it isn't related to the cache, but to the rump fs server, or it's usage.")
This means at the moment if I use something and anything goes wrong there are many possible suspects: - Documentation is outdated. - Documentation has something missing which is written in some release note/documentation - Information from last release note is also already outdated - I have done something wrong - some component does not work as expected (e.g. from time to time you read "haven't used it for some time, script no longer works") - problem with the correct setup or the way components work together.
Every issue with a component can be a possible security bug.
Benefits: - Updates of the documentation will help other developers or people just trying out the system - Test scripts and reacting on the results will produce a system which is more stable
How? First minimal step: - set up a continues integration system. - create at least one test for every component ( later: create unit tests to test e.g. every path, null values, wrong values and so on, but for start just do a test which tests the expected behaviour of the system. ) - create an easy to view output, e.g. Component | Red-Green (leading to a finer granulated page with Component | Test | Red-Green | Error output) With the automated run after a check in you can see wether a component still runs after changes (Later: auto reject changes which lead to failed runs). That leads to 2 major things: - Third party developers can see wether a component is generally usable - As it is clear which action lead to a failed run the bug can be found faster and the time to fix shoudl be lower
Best regards Wolfgang
-----Ursprüngliche Nachricht----- From: Norman Feske Sent: Monday, December 22, 2014 12:22 PM To: Genode OS Framework Mailing List Subject: Roadmap 2015
Hello everybody,
with New Year in sight, it is time to make up our minds regarding the plans for 2015. Everyone of you is invited to suggest directions that you find worthwhile to pursue - or even better - share your concrete plans with us. I intend to finalize the road map for 2015 by mid of January.
Personally, I have three ambitions, namely the use of Genode as general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me briefly revisit each of them.
Genode as general-purpose OS ----------------------------
We made big steps for pursuing Genode as general-purpose OS on x86-based platforms. I'd particularly like to highlight the following achievements:
* The use of Rump kernels as file-system providers * VirtualBox with support for shared folders and guest networking * Intel wireless stack * New GUI stack
That said, even though we are proud about the progress, we are still not there yet. So what keeps us back? I think that the answer is actually not technical. My observation is that each of us developers used to concentrate on individual features or technical challenges. But the integration of sophisticated system scenarios was left to only a few of us. Such integration feats were mainly motivated by a particular project or by a presentation. In order to make Genode fit for regular use, we will first need to make the composing of advanced systems a habit for most of the regular developers.
I'd like to keep the topic as first priority in 2015 but concentrate less on features (as I think the feature set for us developers is fairly complete) but more on looking at Genode in a holistic way. I would like to see the following things realized:
* A system booting from USB storage, which contains a VirtualBox instance running a regular Linux-based OS besides native Genode components. A shared folder is to be used to bridge both worlds. We start out with working in the guest OS and then successively move functionalities over to the Genode world. Those functionalities are: * Editing text, e.g., using Vim in a Noux environment * Creating and starting Genode configurations on the fly * Using a web browser in Genode * Moving emails to the Genode world * Use the Genode tool chain * Using Git I expect that we will stumble over several small issues and inconveniences on our way, which gives us the right motivation to rectify those things.
* A way to easily install and use pre-packaged Genode subsystems. I'd like to remove the burden to compile Qt5 + WebKit for everyone who wants to use a web browser on Genode.
* Tools for looking at the system at runtime to identify performance hot spots. I'd love it identify strangely behaving components as easily as running 'top' on Linux.
* A solid solution for platform drivers (supporting MSIs and the hot-plugging of devices). I.e., I'd like to access the content of a plugged-in USB stick without the need to reboot the machine.
* The evolution of our capability-based desktop environment, driven by our actual requirements stemming from the daily use of Genode. The system should be fun to use and put the user in control at all times.
* Making Genode components and libraries binary compatible across different kernels. I see this as a prerequisite to offer binary packages of Genode subsystems. The new dynamic linker introduced in Genode 14.11 is an important step. The next step is the unification of the Genode API across all kernels.
Base-hw kernel --------------
In 2014, our base-hw kernel made the transformation from a research vehicle to a feasible base platform for Genode. The past year brought a huge jump in terms of performance, MP support, a clean internal structure, and a new scheduler.
In 2015 it will eventually become product-quality software. The only missing element is the support for capability-based security, which is being worked on right now. For base-hw, my wish list looks as follows:
* Capability-based security * Integration of our existing ARM virtualization research
seL4 kernel -----------
I feel that the seL4 kernel and Genode could complement each other rather well. The use of seL4 as kernel would make Genode very appealing in application areas where both the kernel's formal verification and Genode's broad feature set are desired. From the perspective of the seL4 developers, Genode would represent the first true microkernel-based general-purpose OS running on their kernel. I would hope that, by supporting seL4 as kernel for Genode, we may create an incentive for both developer teams to start collaborating more closely.
These are my thoughts. I am looking forward to your ideas and comments.
Cheers Norman