Hello and happy New Year everybody,
the advent of 2013 is a good opportunity to make up our minds about Genode's road map for this year. But before I will start with explaining my preferences, I'd like to outline my thoughts about the last year's road map.
In 2012, we labeled our activities as "Eating our own dog food". Our goal was to bring Genode into a shape that makes it usable as working environment for conducting Genode development. On our road-map website (http://genode.org/about/road-map) we listed a long list of desirable goals. Looking through the list makes me proud of our achievements. Just to name a few highlights, there is the ability to build Genode on Genode, SSH, lighttpd, the new file-system infrastructure, the new DDE linux and DDE OSS. But even though the list is impressive and the pieces nicely come together, we are not quite there yet to realistically make the switch to Genode as development environment. Two major missing points are a solid UI concept that leverages Genode's unique architecture and a "real" file system. You will find those points in my suggestions for this year's road map below.
Even though we missed our ambitious main goal for 2012, there is no cause for despair. There are indeed many achievements in addition to our road-map items to be proud of. The most visible addition is the thorough support for ARM-based platforms reaching from versatile express, over freescale i.MX, to OMAP4. Another amazing development is the added base-hw platform that enables Genode to be executed without a 3rd-party kernel. Furthermore, the largely revised support for the Linux base platform makes Genode fit to be used as component framework on Linux, which is a quite unexpected turn of events.
So what is coming next?
From my point of view, I see four major construction sites that we
should address this year: framework infrastructure, self-hosting, tooling and optimizations, and hardware support.
Framework infrastructure ========================
The primary group of people Genode tries to cater well are developers and integrators of systems. Genode is meant as a tool box to empower those people to build real-world component-based system solutions. From this audience, we receive requests for improvements in the following areas:
* Multi-processor support: On some base platforms, SMP support is available but the framework still misses a holistic concept to manage and configure the use of multiple CPUs.
* Storage: Block-device access is a general concern. Even though we laid the foundations for Genode's storage infrastructure, several pieces are still missing, in particular a "real" (non-FAT) file system, block/file/directory caching, and I/O scheduling. Without those pieces, there is no way to achieve the application performance that we desire.
* Networking: The current TCP/IP performance using lwIP has room for improvement. So I'd like to find a solution to bring TCP/IP performance on Genode on par with Linux. Maybe this means to find the bottlenecks in our lwIP port, or even going for another TCP/IP stack?
* Qt5: Now that Qt5 is officially released, we should consider to switch from Qt4 to Qt5.
* Low-latency audio: The current audio_out-session interface was our first shot into the direction of audio processing. To enable use cases where streaming audio and sporadic sounds must be accommodated at the same time, we need to revise our approach. There is already work in progress on this topic.
* Cryptography * Random numbers * Block-device encryption
Self-hosting ============
The second major topic is redeeming the promise stated for the past year - using Genode as a real-world OS. The following pieces are missing. Compared to the list on the old road map, this one is rather small. So I am very positive!
* UI concept for pleasant working environment * Tiled window manager * Terminal improvements (e.g., scroll buffer) * Noux improvements (e.g., signals)
* Tools * Git (work is already in progress) * Mail user agent * Instant-messaging software * Support for 'make prepare' (e.g., SVN, wget, mawk) * Support for run tool: expect, Qemu
Tooling and optimization ========================
Now that Genode's work loads get ever more complex, we feel the drastically increased need to understand its inner behavior and detect possible black holes where the performance goes.
When the system scenarios were rather small, printf-debugging was quite feasible. But now, with multiple instances of Noux running concurrently with several drivers, we need better tools for understanding, debugging, and tracing the system. In a component-based system like Genode, the creation of such tooling support of especially challenging because we need to walk on new grounds. In my opinion, good tooling is key to direct our efforts spent with performance optimizations. The goal should be to ultimately debunk the slow performance of microkernel-based systems as a myth.
Hardware support ================
The attractiveness of our framework corresponds to the degree of hardware support. Since we want to make Genode more attractive, we need to continue our efforts with creating custom drivers, porting drivers, and enabling platforms. The following points are the most interesting ones from my point of view:
* Intel architecture * IOMMU support * Improved virtualization support (Vancouver on NOVA) * Intel wireless * ARM architecture * Extending support for SoC platforms * TrustZone
Of course, Genode's road map for 2013 is not meant to be dictated by me. Please chime in, discuss the topics above and propose additional items. I hope that we will reach consent for the goals of this year by mid January. Then I will update the official road map on the website.
Cheers Norman
Dear Norman,
Congratulations to you and the Genode team on your 2012 achievements. You are truly doing a fantastic job!
W.r.t 2013 road map, we have already discussed this but I thought I would bring it to the broader audience.
On the theme of debunking the low-performance myth, I personally would like to see better SMP support. Ideally I would like to see Genod's 'core' process become multi-threaded (with service threads on each core) so that we can minimize cross-core IPC and cross-application interference. This would allow more localized thread/memory management etc. as well as IRQ handling. Doing a better job of resource management and QoS partitioning is a potential strength over monolithic kernels that we should (as a community) be striving for.
I also agree that a shift towards more "native" drivers and filesystems would be good. Although using wrappers such as the various DDE frameworks helps to get off the ground fast, it comes at a cost of performance and reduces the ability to manage resources in the Genode way.
Ourselves, we plan to look at a native implementation of a 10G driver (probably Myricom but yet TBD). We are also interested in a more scalable and better performing TCP stack.
Finally I would second your opinion about debugging tools being very important to the broader adoption of Genode.
All the best, Daniel
On 01/04/2013 04:55 AM, Norman Feske wrote:
Hello and happy New Year everybody,
the advent of 2013 is a good opportunity to make up our minds about Genode's road map for this year. But before I will start with explaining my preferences, I'd like to outline my thoughts about the last year's road map.
In 2012, we labeled our activities as "Eating our own dog food". Our goal was to bring Genode into a shape that makes it usable as working environment for conducting Genode development. On our road-map website (http://genode.org/about/road-map) we listed a long list of desirable goals. Looking through the list makes me proud of our achievements. Just to name a few highlights, there is the ability to build Genode on Genode, SSH, lighttpd, the new file-system infrastructure, the new DDE linux and DDE OSS. But even though the list is impressive and the pieces nicely come together, we are not quite there yet to realistically make the switch to Genode as development environment. Two major missing points are a solid UI concept that leverages Genode's unique architecture and a "real" file system. You will find those points in my suggestions for this year's road map below.
Even though we missed our ambitious main goal for 2012, there is no cause for despair. There are indeed many achievements in addition to our road-map items to be proud of. The most visible addition is the thorough support for ARM-based platforms reaching from versatile express, over freescale i.MX, to OMAP4. Another amazing development is the added base-hw platform that enables Genode to be executed without a 3rd-party kernel. Furthermore, the largely revised support for the Linux base platform makes Genode fit to be used as component framework on Linux, which is a quite unexpected turn of events.
So what is coming next?
From my point of view, I see four major construction sites that we
should address this year: framework infrastructure, self-hosting, tooling and optimizations, and hardware support.
Framework infrastructure
The primary group of people Genode tries to cater well are developers and integrators of systems. Genode is meant as a tool box to empower those people to build real-world component-based system solutions. From this audience, we receive requests for improvements in the following areas:
Multi-processor support: On some base platforms, SMP support is available but the framework still misses a holistic concept to manage and configure the use of multiple CPUs.
Storage: Block-device access is a general concern. Even though we laid the foundations for Genode's storage infrastructure, several pieces are still missing, in particular a "real" (non-FAT) file system, block/file/directory caching, and I/O scheduling. Without those pieces, there is no way to achieve the application performance that we desire.
Networking: The current TCP/IP performance using lwIP has room for improvement. So I'd like to find a solution to bring TCP/IP performance on Genode on par with Linux. Maybe this means to find the bottlenecks in our lwIP port, or even going for another TCP/IP stack?
Qt5: Now that Qt5 is officially released, we should consider to switch from Qt4 to Qt5.
Low-latency audio: The current audio_out-session interface was our first shot into the direction of audio processing. To enable use cases where streaming audio and sporadic sounds must be accommodated at the same time, we need to revise our approach. There is already work in progress on this topic.
Cryptography
- Random numbers
- Block-device encryption
Self-hosting
The second major topic is redeeming the promise stated for the past year
- using Genode as a real-world OS. The following pieces are missing.
Compared to the list on the old road map, this one is rather small. So I am very positive!
UI concept for pleasant working environment
- Tiled window manager
- Terminal improvements (e.g., scroll buffer)
- Noux improvements (e.g., signals)
Tools
- Git (work is already in progress)
- Mail user agent
- Instant-messaging software
- Support for 'make prepare' (e.g., SVN, wget, mawk)
- Support for run tool: expect, Qemu
Tooling and optimization
Now that Genode's work loads get ever more complex, we feel the drastically increased need to understand its inner behavior and detect possible black holes where the performance goes.
When the system scenarios were rather small, printf-debugging was quite feasible. But now, with multiple instances of Noux running concurrently with several drivers, we need better tools for understanding, debugging, and tracing the system. In a component-based system like Genode, the creation of such tooling support of especially challenging because we need to walk on new grounds. In my opinion, good tooling is key to direct our efforts spent with performance optimizations. The goal should be to ultimately debunk the slow performance of microkernel-based systems as a myth.
Hardware support
The attractiveness of our framework corresponds to the degree of hardware support. Since we want to make Genode more attractive, we need to continue our efforts with creating custom drivers, porting drivers, and enabling platforms. The following points are the most interesting ones from my point of view:
- Intel architecture
- IOMMU support
- Improved virtualization support (Vancouver on NOVA)
- Intel wireless
- ARM architecture
- Extending support for SoC platforms
- TrustZone
Of course, Genode's road map for 2013 is not meant to be dictated by me. Please chime in, discuss the topics above and propose additional items. I hope that we will reach consent for the goals of this year by mid January. Then I will update the official road map on the website.
Cheers Norman
Thanks for this bulletin, seriously. I just joined the list, and while I understand the importance of an "agnostic" framework, I was having difficulty comprehending your goals.
Regards from Canada, John
On Fri, Jan 4, 2013 at 8:55 AM, Norman Feske <norman.feske@...1...>wrote:
Hello and happy New Year everybody,
the advent of 2013 is a good opportunity to make up our minds about Genode's road map for this year. But before I will start with explaining my preferences, I'd like to outline my thoughts about the last year's road map.
In 2012, we labeled our activities as "Eating our own dog food". Our goal was to bring Genode into a shape that makes it usable as working environment for conducting Genode development. On our road-map website (http://genode.org/about/road-map) we listed a long list of desirable goals. Looking through the list makes me proud of our achievements. Just to name a few highlights, there is the ability to build Genode on Genode, SSH, lighttpd, the new file-system infrastructure, the new DDE linux and DDE OSS. But even though the list is impressive and the pieces nicely come together, we are not quite there yet to realistically make the switch to Genode as development environment. Two major missing points are a solid UI concept that leverages Genode's unique architecture and a "real" file system. You will find those points in my suggestions for this year's road map below.
Even though we missed our ambitious main goal for 2012, there is no cause for despair. There are indeed many achievements in addition to our road-map items to be proud of. The most visible addition is the thorough support for ARM-based platforms reaching from versatile express, over freescale i.MX, to OMAP4. Another amazing development is the added base-hw platform that enables Genode to be executed without a 3rd-party kernel. Furthermore, the largely revised support for the Linux base platform makes Genode fit to be used as component framework on Linux, which is a quite unexpected turn of events.
So what is coming next?
From my point of view, I see four major construction sites that we
should address this year: framework infrastructure, self-hosting, tooling and optimizations, and hardware support.
Framework infrastructure
The primary group of people Genode tries to cater well are developers and integrators of systems. Genode is meant as a tool box to empower those people to build real-world component-based system solutions. From this audience, we receive requests for improvements in the following areas:
Multi-processor support: On some base platforms, SMP support is available but the framework still misses a holistic concept to manage and configure the use of multiple CPUs.
Storage: Block-device access is a general concern. Even though we laid the foundations for Genode's storage infrastructure, several pieces are still missing, in particular a "real" (non-FAT) file system, block/file/directory caching, and I/O scheduling. Without those pieces, there is no way to achieve the application performance that we desire.
Networking: The current TCP/IP performance using lwIP has room for improvement. So I'd like to find a solution to bring TCP/IP performance on Genode on par with Linux. Maybe this means to find the bottlenecks in our lwIP port, or even going for another TCP/IP stack?
Qt5: Now that Qt5 is officially released, we should consider to switch from Qt4 to Qt5.
Low-latency audio: The current audio_out-session interface was our first shot into the direction of audio processing. To enable use cases where streaming audio and sporadic sounds must be accommodated at the same time, we need to revise our approach. There is already work in progress on this topic.
Cryptography
- Random numbers
- Block-device encryption
Self-hosting
The second major topic is redeeming the promise stated for the past year
- using Genode as a real-world OS. The following pieces are missing.
Compared to the list on the old road map, this one is rather small. So I am very positive!
UI concept for pleasant working environment
- Tiled window manager
- Terminal improvements (e.g., scroll buffer)
- Noux improvements (e.g., signals)
Tools
- Git (work is already in progress)
- Mail user agent
- Instant-messaging software
- Support for 'make prepare' (e.g., SVN, wget, mawk)
- Support for run tool: expect, Qemu
Tooling and optimization
Now that Genode's work loads get ever more complex, we feel the drastically increased need to understand its inner behavior and detect possible black holes where the performance goes.
When the system scenarios were rather small, printf-debugging was quite feasible. But now, with multiple instances of Noux running concurrently with several drivers, we need better tools for understanding, debugging, and tracing the system. In a component-based system like Genode, the creation of such tooling support of especially challenging because we need to walk on new grounds. In my opinion, good tooling is key to direct our efforts spent with performance optimizations. The goal should be to ultimately debunk the slow performance of microkernel-based systems as a myth.
Hardware support
The attractiveness of our framework corresponds to the degree of hardware support. Since we want to make Genode more attractive, we need to continue our efforts with creating custom drivers, porting drivers, and enabling platforms. The following points are the most interesting ones from my point of view:
- Intel architecture
- IOMMU support
- Improved virtualization support (Vancouver on NOVA)
- Intel wireless
- ARM architecture
- Extending support for SoC platforms
- TrustZone
Of course, Genode's road map for 2013 is not meant to be dictated by me. Please chime in, discuss the topics above and propose additional items. I hope that we will reach consent for the goals of this year by mid January. Then I will update the official road map on the website.
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
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi John,
welcome to the list and thank you for the feedback!
Norman
On 01/04/2013 06:46 PM, John Bessa wrote:
Thanks for this bulletin, seriously. I just joined the list, and while I understand the importance of an "agnostic" framework, I was having difficulty comprehending your goals.
Regards from Canada, John
Hi Daniel,
On the theme of debunking the low-performance myth, I personally would like to see better SMP support. Ideally I would like to see Genod's 'core' process become multi-threaded (with service threads on each core) so that we can minimize cross-core IPC and cross-application interference. This would allow more localized thread/memory management etc. as well as IRQ handling. Doing a better job of resource management and QoS partitioning is a potential strength over monolithic kernels that we should (as a community) be striving for.
I wholeheartedly agree and would welcome any input from your side helping us to get there.
I also agree that a shift towards more "native" drivers and filesystems would be good. Although using wrappers such as the various DDE frameworks helps to get off the ground fast, it comes at a cost of performance and reduces the ability to manage resources in the Genode way.
Ourselves, we plan to look at a native implementation of a 10G driver (probably Myricom but yet TBD). We are also interested in a more scalable and better performing TCP stack.
Maybe there is the chance to somehow team up with Julian (blitz at GitHub) on this topic? As far as I know, he is genuinely interested in high-performance networking and has profound experience in the domain.
Finally I would second your opinion about debugging tools being very important to the broader adoption of Genode.
If you have ideas or visions of how a specific tool of your liking would look like, please do not hesitate to share them on the mailing list. Concrete requirements would certainly help us to design solutions that are actually useful.
Thanks for commenting on our road map. It seems that your interests are pretty much aligned with my planning.
Cheers Norman
On Sat, 2013-01-05 at 19:23 +0100, Norman Feske wrote:
Ourselves, we plan to look at a native implementation of a 10G driver (probably Myricom but yet TBD). We are also interested in a more scalable and better performing TCP stack.
Maybe there is the chance to somehow team up with Julian (blitz at GitHub) on this topic? As far as I know, he is genuinely interested in high-performance networking and has profound experience in the domain.
Thanks for the compliment. :)
Maybe there is time to talk about this at FOSDEM. I have 10G Intel hardware available and will probably do a native driver for our userland(s) soonish, which would be available under GPL. If you do not need anything fancy (IPsec offload, weird PHY programming, ...), it should be easily portable to Genode.
Julian
Hello,
the road map on our website has been updated just now. It is based on our discussion and the text of my original proposal:
http://genode.org/about/road-map
Cheers Norman
-
Daniel Waddington -
John Bessa -
Julian Stecklina -
Norman Feske