Dear Genode community,
the end of the strange year 2020 comes in sight. So now it is time to kick off our annual road-map discussion. I'll keep up with our tradition of reviewing the past 12 months from my personal perspective, dropping my ideas for the upcoming year, and inviting you to share your ideas and plans.
Review of 2020 --------------
The overarching theme of our road map for 2020 was "Dwarfing the barrier of entry", which expressed the ambition to reach a wider audience. On that account, we identified four promising directions: First, making Sculpt OS palatable for a wider circle. Second, fostering the public perception of the high quality of Genode to reinforce the confidence of people who are sceptical towards novel operating-system technology. Third, lowering the barrier of entry by providing frictionless tooling. And fourth, publicly presenting use cases that prove the fitness and flexibility of Genode.
These directions certainly did a good job of motivating the working topics of this year's four releases [1,2,3,4].
[1] https://genode.org/documentation/release-notes/20.02 [2] https://genode.org/documentation/release-notes/20.05 [3] https://genode.org/documentation/release-notes/20.08 [4] https://genode.org/documentation/release-notes/20.11
The UI improvements of Sculpt OS in version 20.02 largely eliminated the need to use the command line, as shown in my live demo [5]. But the work on the user-visible side of Sculpt has admittedly dried up a bit since spring time. Software quality has been a continuous topic. Personally, I dedicated a lot of energy to the improvement and consolidation of our POSIX support (Noux vs. libc) and the related infrastructure like the VFS server.
[5] https://www.youtube.com/watch?v=vmgWgzeKAjU
That said, despite the many technical advances, the stated soft goal of reaching a broader audience remains fairly distant. Genode has not seen a significantly wider adoption by the open-source community at large compared to one year ago.
On the other hand, regarding our stated commitment to 64-bit ARM hardware, in particular supporting the NXP i.MX8 SoC, there is a strong sense of accomplishment, which makes me proud. The depth and breadth of this line of work has been fantastic. I'm speaking of 64-bit multi-core virtualization, HDMI, touch input, OLED, networking, LTE, USB, clock and power management, VirtIO, up to running Sculpt OS on this platform. It is a huge success story on a technical account.
Regarding our reach to a broader community, we are super excited about the prospect of combining Genode with the MNT-Reform laptop that is based on the i.MX8 SoC. When speaking of i.MX8 one year ago, I also had the Librem5 in mind - envisioning Genode on a smart-phone form factor. But that hope remained abstract as we did not succeed to establish a correspondence with the makers of the Librem5. The vision of a Genode-based smart phone, however, has become stronger than ever (see below).
While reading the paragraphs above, you may sense my ambiguous feelings about the past year's road map. I think we missed the stated goal. I also think that we excelled at technological progress. For us developers, the road map serves primarily as orientation for our technical work. But since the past year's goal of increasing adoption hasn't been a technical one, no level of technical excellence will magically bring us there. So the goal was a bit delusionally to begin with. Let us lift this pressure for the next year and concentrate on the technical level.
My personal ambitions for 2021 ------------------------------
* By the end of the year, I want to use a Genode-based mobile phone, replacing my current Nokia 3720. I'll focus on the _Pinephone_. In fact, I have already taken the first baby steps and will continue to thoroughly document this line of work at https://genodians.org.
* I see plenty of opportunities for optimization throughout Genode and would like to make _optimization_ the motto of the year. The following ideas are spontaneously crossing my mind:
- Profiling and tuning of Unix-like workloads, in particular by looking at file-system access patterns. - Fostering the batching of async I/O, e.g., increasing the chance for the batching of network packets. - Let our ARM tool chain use the hard-float calling convention. - Replace the allocator of our C runtime by jemalloc. - Reducing the overhead of our POSIX TLS mechanism. - Taking XML parsing off the critical path for the dynamic reconfiguration of init. - Removing indirections, in particular the old libc plugin interface. - Reducing the inflation of binaries by C++ templates. - Improving compilation times by reducing header interdependencies. - Merging core's CPU and PD service into one.
* I'm convinced that we have to dramatically reduce the engineering effort needed to port device drivers from the Linux kernel to Genode. Backed by our practical DDE-Linux experience, a few ideas have formed in the back of my head. They want out. So I see my work with the Pinephone as a welcome opportunity for experimenting in this direction.
What's your perspective? ------------------------
For drafting the road map of next year, I'm eagerly interested in the perspective of my fellow developers and of course users of Genode.
How do you perceive the outcome of the year?
What areas would you wish to concentrate on?
Where do you see untapped potential of Genode?
How do you envision Genode in December 2021?
I would very much appreciate your input for forming a rough picture of next year. Of course, not all ideas will make it to the road map. Economic constraints and the willingness of pro-active participation play a major role. Regarding the timeline, I plan to announce the official road map for 2021 in mid of January.
Cheers Norman
Hi all,
I like Norman's vision of having a Genode-based mobile phone by the end of 2021 and am stoked to contribute to this mission. I almost ordered a pinephone some weeks ago but talked myself out of it because I was not ready to put in a lot of work. Yet, the perspective of running Genode on this phone completely changes the picture ;-) Besides the technological obstacles such as porting device drivers, there is also the question of usability. I think a basic support/integration of web apps would make the mobile Genode already quite usable.
I also like that Norman mentioned optimisation. I have a few ideas in the back of my head regarding performance optimisation and debugging. I would very much like to get some system-level tracing infrastructure running. As I've been working with Lttng this year (outside the Genode sphere), I thought having a similar functionality on Genode could dramatically simplify identifying bottlenecks and race conditions. The nice thing is that the developers behind Lttng established the Common Trace Format to store trace data. Thus, once we get a CTF trace out of Genode, we could use all the existing analysis and visualisation tools.
Cheers Johannes
Hi Johannes,
thank you for chiming in!
All what you write is just perfectly aligned with my plans. That is so cool to read.
On 18.12.20 19:00, Johannes Schlatow wrote:
Besides the technological obstacles such as porting device drivers, there is also the question of usability. I think a basic support/integration of web apps would make the mobile Genode already quite usable.
Indeed. I'm secretly glimpsing towards Sailfish OS, which apparently uses Qt5/QML as the basis for the application API. Since Genode supports QML already, maybe we could explore the option to bridge the Sailfish API to Genode, leveraging Goa? No concrete plan, just vague ideas.
While playing around with various distributions on the Pinephone, the Morph browser of Ubuntu Touch left a very good impression me. It just happens to be based on QML and QtWebEngine also.
I also like that Norman mentioned optimisation. I have a few ideas in the back of my head regarding performance optimisation and debugging. I would very much like to get some system-level tracing infrastructure running. As I've been working with Lttng this year (outside the Genode sphere), I thought having a similar functionality on Genode could dramatically simplify identifying bottlenecks and race conditions. The nice thing is that the developers behind Lttng established the Common Trace Format to store trace data. Thus, once we get a CTF trace out of Genode, we could use all the existing analysis and visualisation tools.
That sounds like a match in heaven. :-)
Cheers Norman
Hi Everybody, As a hobbyist who's been following Genode for about a year now (I was running Sculpt on my home computer for a few months), I thought I would offer a few thoughts. Since I mostly do stuff for fun and at a slow pace, I don't expect to be influential in any serious way, but perhaps the perspective of hobby users is valuable nonetheless? Overall I'm very impressed with Genode/Sculpt - the philosophy and approach is pretty cool, and I have some successes with it. For example, I was able to port the Qt version of the "2048" game, and recently I have been trying to port the HelenOS driver for AR9271 usb wifi dongle - it is work in progress and non-functional currently. I also appreciate the level of active development going on - each new update brings cool stuff, so I think the past year of Genode updates was interesting to see.
If there's one wish I have it would be better hardware support and resiliency. Currently, unless I misunderstand, the hardware support list mostly reflects the hardware that Genode Labs uses, and there doesn't see to be much dynamic handling of identifying and loading drivers. Example 1 - Sculpt will try to load a PS2 driver even on my Apple hardware that doesn't have any, leading to system crash. Example 2 - Sculpt uses pretty simple hard-coded logic to select which framebuffer driver to use, when I was expecting an XML file somewhere to allow more fine-grained control of which vendor/product IDs to assign to which driver (and also to identify and match other drivers, I guess). Example 3 - When the FB driver crashes, the rest of the system is resilient and continues to run. But, of course this is nearly useless because there is no way to reset the driver. Given my understanding of the component-based architecture, it seems like these things shouldn't be insurmountable issues. It should be possible to identify a failed component, kill it, and replace with a new instance, I think? It would be fun, in non-embedded applications, to be able to compile an experimental driver within a VM, push the result back to the running system, test it, tweak and recompile, etc. With that kind of workflow, maybe we could hope for more experimental/community drivers, at least on PC hardware?
Anyhow, those are my thoughts, thanks for making Genode!
Regards, Colin
On Fri, Dec 18, 2020 at 9:00 AM Norman Feske norman.feske@genode-labs.com wrote:
Dear Genode community,
the end of the strange year 2020 comes in sight. So now it is time to kick off our annual road-map discussion. I'll keep up with our tradition of reviewing the past 12 months from my personal perspective, dropping my ideas for the upcoming year, and inviting you to share your ideas and plans.
Review of 2020
The overarching theme of our road map for 2020 was "Dwarfing the barrier of entry", which expressed the ambition to reach a wider audience. On that account, we identified four promising directions: First, making Sculpt OS palatable for a wider circle. Second, fostering the public perception of the high quality of Genode to reinforce the confidence of people who are sceptical towards novel operating-system technology. Third, lowering the barrier of entry by providing frictionless tooling. And fourth, publicly presenting use cases that prove the fitness and flexibility of Genode.
These directions certainly did a good job of motivating the working topics of this year's four releases [1,2,3,4].
[1] https://genode.org/documentation/release-notes/20.02 [2] https://genode.org/documentation/release-notes/20.05 [3] https://genode.org/documentation/release-notes/20.08 [4] https://genode.org/documentation/release-notes/20.11
The UI improvements of Sculpt OS in version 20.02 largely eliminated the need to use the command line, as shown in my live demo [5]. But the work on the user-visible side of Sculpt has admittedly dried up a bit since spring time. Software quality has been a continuous topic. Personally, I dedicated a lot of energy to the improvement and consolidation of our POSIX support (Noux vs. libc) and the related infrastructure like the VFS server.
[5] https://www.youtube.com/watch?v=vmgWgzeKAjU
That said, despite the many technical advances, the stated soft goal of reaching a broader audience remains fairly distant. Genode has not seen a significantly wider adoption by the open-source community at large compared to one year ago.
On the other hand, regarding our stated commitment to 64-bit ARM hardware, in particular supporting the NXP i.MX8 SoC, there is a strong sense of accomplishment, which makes me proud. The depth and breadth of this line of work has been fantastic. I'm speaking of 64-bit multi-core virtualization, HDMI, touch input, OLED, networking, LTE, USB, clock and power management, VirtIO, up to running Sculpt OS on this platform. It is a huge success story on a technical account.
Regarding our reach to a broader community, we are super excited about the prospect of combining Genode with the MNT-Reform laptop that is based on the i.MX8 SoC. When speaking of i.MX8 one year ago, I also had the Librem5 in mind - envisioning Genode on a smart-phone form factor. But that hope remained abstract as we did not succeed to establish a correspondence with the makers of the Librem5. The vision of a Genode-based smart phone, however, has become stronger than ever (see below).
While reading the paragraphs above, you may sense my ambiguous feelings about the past year's road map. I think we missed the stated goal. I also think that we excelled at technological progress. For us developers, the road map serves primarily as orientation for our technical work. But since the past year's goal of increasing adoption hasn't been a technical one, no level of technical excellence will magically bring us there. So the goal was a bit delusionally to begin with. Let us lift this pressure for the next year and concentrate on the technical level.
My personal ambitions for 2021
By the end of the year, I want to use a Genode-based mobile phone, replacing my current Nokia 3720. I'll focus on the _Pinephone_. In fact, I have already taken the first baby steps and will continue to thoroughly document this line of work at https://genodians.org.
I see plenty of opportunities for optimization throughout Genode and would like to make _optimization_ the motto of the year. The following ideas are spontaneously crossing my mind:
- Profiling and tuning of Unix-like workloads, in particular by looking at file-system access patterns.
- Fostering the batching of async I/O, e.g., increasing the chance for the batching of network packets.
- Let our ARM tool chain use the hard-float calling convention.
- Replace the allocator of our C runtime by jemalloc.
- Reducing the overhead of our POSIX TLS mechanism.
- Taking XML parsing off the critical path for the dynamic reconfiguration of init.
- Removing indirections, in particular the old libc plugin interface.
- Reducing the inflation of binaries by C++ templates.
- Improving compilation times by reducing header interdependencies.
- Merging core's CPU and PD service into one.
I'm convinced that we have to dramatically reduce the engineering effort needed to port device drivers from the Linux kernel to Genode. Backed by our practical DDE-Linux experience, a few ideas have formed in the back of my head. They want out. So I see my work with the Pinephone as a welcome opportunity for experimenting in this direction.
What's your perspective?
For drafting the road map of next year, I'm eagerly interested in the perspective of my fellow developers and of course users of Genode.
How do you perceive the outcome of the year?
What areas would you wish to concentrate on?
Where do you see untapped potential of Genode?
How do you envision Genode in December 2021?
I would very much appreciate your input for forming a rough picture of next year. Of course, not all ideas will make it to the road map. Economic constraints and the willingness of pro-active participation play a major role. Regarding the timeline, I plan to announce the official road map for 2021 in mid of January.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi! Sorry for topposting! Thanks for everything made in 2020 and exiting (as always ) thoughts about 2021.
I decided to send out my own "roadmap" instead of polluting this thread.
The best thing with Genode imho is that it doesn't force me of what I want to run. If I need base-hw with a couple of drivers it doesn't include a big mass of software or unrelated drivers. It is also easy to port to new hardware thanks to the abstraction being quite easy to grasp.
I think your roadmap is great. PinePhone is exciting but would need a big rethink on UI,
Michael
On Sat, 19 Dec 2020 at 05:46, Colin Parker cvparker@gmail.com wrote:
Hi Everybody, As a hobbyist who's been following Genode for about a year now (I was running Sculpt on my home computer for a few months), I thought I would offer a few thoughts. Since I mostly do stuff for fun and at a slow pace, I don't expect to be influential in any serious way, but perhaps the perspective of hobby users is valuable nonetheless? Overall I'm very impressed with Genode/Sculpt - the philosophy and approach is pretty cool, and I have some successes with it. For example, I was able to port the Qt version of the "2048" game, and recently I have been trying to port the HelenOS driver for AR9271 usb wifi dongle - it is work in progress and non-functional currently. I also appreciate the level of active development going on - each new update brings cool stuff, so I think the past year of Genode updates was interesting to see.
If there's one wish I have it would be better hardware support and resiliency. Currently, unless I misunderstand, the hardware support list mostly reflects the hardware that Genode Labs uses, and there doesn't see to be much dynamic handling of identifying and loading drivers. Example 1 - Sculpt will try to load a PS2 driver even on my Apple hardware that doesn't have any, leading to system crash. Example 2 - Sculpt uses pretty simple hard-coded logic to select which framebuffer driver to use, when I was expecting an XML file somewhere to allow more fine-grained control of which vendor/product IDs to assign to which driver (and also to identify and match other drivers, I guess). Example 3 - When the FB driver crashes, the rest of the system is resilient and continues to run. But, of course this is nearly useless because there is no way to reset the driver. Given my understanding of the component-based architecture, it seems like these things shouldn't be insurmountable issues. It should be possible to identify a failed component, kill it, and replace with a new instance, I think? It would be fun, in non-embedded applications, to be able to compile an experimental driver within a VM, push the result back to the running system, test it, tweak and recompile, etc. With that kind of workflow, maybe we could hope for more experimental/community drivers, at least on PC hardware?
Anyhow, those are my thoughts, thanks for making Genode!
Regards, Colin
On Fri, Dec 18, 2020 at 9:00 AM Norman Feske norman.feske@genode-labs.com wrote:
Dear Genode community,
the end of the strange year 2020 comes in sight. So now it is time to kick off our annual road-map discussion. I'll keep up with our tradition of reviewing the past 12 months from my personal perspective, dropping my ideas for the upcoming year, and inviting you to share your ideas and plans.
Review of 2020
The overarching theme of our road map for 2020 was "Dwarfing the barrier of entry", which expressed the ambition to reach a wider audience. On that account, we identified four promising directions: First, making Sculpt OS palatable for a wider circle. Second, fostering the public perception of the high quality of Genode to reinforce the confidence of people who are sceptical towards novel operating-system technology. Third, lowering the barrier of entry by providing frictionless tooling. And fourth, publicly presenting use cases that prove the fitness and flexibility of Genode.
These directions certainly did a good job of motivating the working topics of this year's four releases [1,2,3,4].
[1] https://genode.org/documentation/release-notes/20.02 [2] https://genode.org/documentation/release-notes/20.05 [3] https://genode.org/documentation/release-notes/20.08 [4] https://genode.org/documentation/release-notes/20.11
The UI improvements of Sculpt OS in version 20.02 largely eliminated the need to use the command line, as shown in my live demo [5]. But the work on the user-visible side of Sculpt has admittedly dried up a bit since spring time. Software quality has been a continuous topic. Personally, I dedicated a lot of energy to the improvement and consolidation of our POSIX support (Noux vs. libc) and the related infrastructure like the VFS server.
[5] https://www.youtube.com/watch?v=vmgWgzeKAjU
That said, despite the many technical advances, the stated soft goal of reaching a broader audience remains fairly distant. Genode has not seen a significantly wider adoption by the open-source community at large compared to one year ago.
On the other hand, regarding our stated commitment to 64-bit ARM hardware, in particular supporting the NXP i.MX8 SoC, there is a strong sense of accomplishment, which makes me proud. The depth and breadth of this line of work has been fantastic. I'm speaking of 64-bit multi-core virtualization, HDMI, touch input, OLED, networking, LTE, USB, clock and power management, VirtIO, up to running Sculpt OS on this platform. It is a huge success story on a technical account.
Regarding our reach to a broader community, we are super excited about the prospect of combining Genode with the MNT-Reform laptop that is based on the i.MX8 SoC. When speaking of i.MX8 one year ago, I also had the Librem5 in mind - envisioning Genode on a smart-phone form factor. But that hope remained abstract as we did not succeed to establish a correspondence with the makers of the Librem5. The vision of a Genode-based smart phone, however, has become stronger than ever (see below).
While reading the paragraphs above, you may sense my ambiguous feelings about the past year's road map. I think we missed the stated goal. I also think that we excelled at technological progress. For us developers, the road map serves primarily as orientation for our technical work. But since the past year's goal of increasing adoption hasn't been a technical one, no level of technical excellence will magically bring us there. So the goal was a bit delusionally to begin with. Let us lift this pressure for the next year and concentrate on the technical level.
My personal ambitions for 2021
By the end of the year, I want to use a Genode-based mobile phone, replacing my current Nokia 3720. I'll focus on the _Pinephone_. In fact, I have already taken the first baby steps and will continue to thoroughly document this line of work at https://genodians.org.
I see plenty of opportunities for optimization throughout Genode and would like to make _optimization_ the motto of the year. The following ideas are spontaneously crossing my mind:
- Profiling and tuning of Unix-like workloads, in particular by looking at file-system access patterns.
- Fostering the batching of async I/O, e.g., increasing the chance for the batching of network packets.
- Let our ARM tool chain use the hard-float calling convention.
- Replace the allocator of our C runtime by jemalloc.
- Reducing the overhead of our POSIX TLS mechanism.
- Taking XML parsing off the critical path for the dynamic reconfiguration of init.
- Removing indirections, in particular the old libc plugin interface.
- Reducing the inflation of binaries by C++ templates.
- Improving compilation times by reducing header interdependencies.
- Merging core's CPU and PD service into one.
I'm convinced that we have to dramatically reduce the engineering effort needed to port device drivers from the Linux kernel to Genode. Backed by our practical DDE-Linux experience, a few ideas have formed in the back of my head. They want out. So I see my work with the Pinephone as a welcome opportunity for experimenting in this direction.
What's your perspective?
For drafting the road map of next year, I'm eagerly interested in the perspective of my fellow developers and of course users of Genode.
How do you perceive the outcome of the year?
What areas would you wish to concentrate on?
Where do you see untapped potential of Genode?
How do you envision Genode in December 2021?
I would very much appreciate your input for forming a rough picture of next year. Of course, not all ideas will make it to the road map. Economic constraints and the willingness of pro-active participation play a major role. Regarding the timeline, I plan to announce the official road map for 2021 in mid of January.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Genodians,
drivers, I guess). Example 3 - When the FB driver crashes, the rest of the system is resilient
and continues to run. > But, of course this is nearly useless because there is no way to reset
the driver. Given my understanding of the component-based architecture, it seems
like these things shouldn't be insurmountable issues. It should be possible to identify
a failed component, kill it, and replace with a new instance, I think?
The way I understand it, this ticket hints at the "restart driver" problem being on its way sometimes soon, which sounds like a whole new can of pure kick-ass awesomeness (did any OS manage to pull off that feat before Genode ?) :
https://github.com/genodelabs/genode/issues/3963
***
As to me, I can't contribute much to the discussion unfortunately : Genode has already been making bounds and leaps in the areas that count for me (AMD compatibility, HDA driver etc) whereas I've been ""idle"" for a long time, thus falling behind more and more. I still expect to get out of the salt mines in the next few weeks and resume my project of running a Be-like OS on top of Genode/nova, something like this:
- finish publishing a (massively cleaned up) copy of the code (aimed at 18.11) that already works so-so, making sure it works good-good *grin*
- once consolidated and cleaned up, work my way through 19.x and 20.x versions of Genode, updating the code as I go, accounting for slight changes in Genode over that time and (especially) the toolchain switch
- once up to date with Genode, get my port itself up to date
- take advantage of the new hardware compatibility introduced recently, profit !
Cedric
Hi Cedric,
great to see a lifesign of you!
On 19.12.20 14:55, ttcoder@netcourrier.com wrote:
As to me, I can't contribute much to the discussion unfortunately : Genode has already been making bounds and leaps in the areas that count for me (AMD compatibility, HDA driver etc) whereas I've been ""idle"" for a long time, thus falling behind more and more.
Admittedly, the FUSE issue is not one of those areas. Unfortunately, we were not able to pick it up in 2020. Hence, I'm hesitant to make any promises in this direction.
- finish publishing a (massively cleaned up) copy of the code (aimed at
18.11) that already works so-so, making sure it works good-good *grin*
- once consolidated and cleaned up, work my way through 19.x and 20.x
versions of Genode, updating the code as I go, accounting for slight changes in Genode over that time and (especially) the toolchain switch
- once up to date with Genode, get my port itself up to date
- take advantage of the new hardware compatibility introduced recently,
profit !
I very much enjoyed following your work on HoG and your writings. :-)
Cheers Norman
Hi Colin,
thank you for having taken the time to present you perspective!
On 19.12.20 05:45, Colin Parker wrote:
As a hobbyist who's been following Genode for about a year now (I was running Sculpt on my home computer for a few months), I thought I would offer a few thoughts. Since I mostly do stuff for fun and at a slow pace, I don't expect to be influential in any serious way, but perhaps the perspective of hobby users is valuable nonetheless? Overall I'm very impressed with Genode/Sculpt - the philosophy and approach is pretty cool, and I have some successes with it. For example, I was able to port the Qt version of the "2048" game, and recently I have been trying to port the HelenOS driver for AR9271 usb wifi dongle - it is work in progress and non-functional currently. I also appreciate the level of active development going on - each new update brings cool stuff, so I think the past year of Genode updates was interesting to see.
It's great to know what's boiling in your kitchen. ;-) I'm happy that your enjoy Genode.
If there's one wish I have it would be better hardware support and resiliency. Currently, unless I misunderstand, the hardware support list mostly reflects the hardware that Genode Labs uses, and there doesn't see to be much dynamic handling of identifying and loading drivers. Example 1 - Sculpt will try to load a PS2 driver even on my Apple hardware that doesn't have any, leading to system crash. Example 2 - Sculpt uses pretty simple hard-coded logic to select which framebuffer driver to use, when I was expecting an XML file somewhere to allow more fine-grained control of which vendor/product IDs to assign to which driver (and also to identify and match other drivers, I guess).
Given the quite small amount of drivers, I found it too early to introduce a formalism. In the longer term, once the driver landscape becomes larger, we will certainly need to rethink this part.
As a general direction of Sculpt, I'm thinking of dissolving the static partitioning of the system into the drivers / leitzentrale / runtime subsystems. E.g., the dynamically started drivers should better be hosted in the runtime subsystem (e.g., as done for the wifi driver today). This way, those drivers and their resources become easier to manage. The separation of these three subsystems - and the distinction between the driver manager and the sculpt manager - was certainly useful during the first evolutionary steps of Sculpt. But since Sculpt has outgrown this phase, these early design decisions deserve a reconsideration.
Example 3 - When the FB driver crashes, the rest of the system is resilient and continues to run. But, of course this is nearly useless because there is no way to reset the driver. Given my understanding of the component-based architecture, it seems like these things shouldn't be insurmountable issues. It should be possible to identify a failed component, kill it, and replace with a new instance, I think? It would be fun, in non-embedded applications, to be able to compile an experimental driver within a VM, push the result back to the running system, test it, tweak and recompile, etc. With that kind of workflow, maybe we could hope for more experimental/community drivers, at least on PC hardware?
I 100% share this vision and think that we are on a good way. The foundations for restarting input and framebuffer drivers are in place now, and network drivers are currently being worked on. We should definitely let Sculpt reap the benefits of this work.
Cheers Norman
Hello Genodians,
a year is almost over and here are my two cents to the roadmap review and wish list. First, I want to say that I'm really proud about the accomplished technical work by Genode over the whole year. Getting Sculpt OS to the i.MX8 board with all the device drivers running is not given nor easy.
Before starting with the ideas for next year, I will review the input of me [0] and see how it was tackled:
The screen-casting topic developed a bit differently then I aspired, but it occupied me over the whole year over and over. On the one hand, in the beginning of the year, I was faced by streaming somehow Android to Genode, which resulted in the Scrcpy work eventually. It was really alien to me in the beginning, required to leave my comfort zone. Reading/understanding/extending an Android app and using Java I had done years back at University. On the other hand, this work also reinforced to me the motivation, not solely the pandemic, to record our demos and new features whenever possible. The Scrcpy work also strongly strengthen the believe that the CPU migration work, done in the second part of the year, is required for ported software. All in all, now I even do video editing and already could support my fellow developers with that :-). Of course, the quality needs improvements but also requires more time. Let's see. Nevertheless, I see it as success - probably, we never uploaded more Genode related videos within one year ever [1][2][3][4].
Even so my envisioned [0] improved AMD support did not make it to the official roadmap, I invested some of my private spare time. The base is the base, and upholding isolation of mad going devices/drivers from the rest of the Genode OS components is crucial. This lead to the work of adding IO-MMU support for AMD machines to get to the same isolation level for device drivers as for the Intel machines. Testing this feature on all of the modern AMD machines of my friends and family took a while to get it done and straight. With an extended Sculpt 20.08 image at hand, I discovered and addressed several other issues, e.g. network and USB. Finally, I started to improve the VBox5 AMD support in my private spare time, which still needs some tweaks. My hope is, that with the next Sculpt OS release more AMD machines are usable actually.
Of course, also several smaller topics and clean up work through the whole Genode framework (e.g. replacing Genode lock with mutex/blockade) were part of the year.
For the next year, I would like to see progress in the following topics and I'm willing to work on them and/or contribute to:
* Extended desktop support using multiple monitors (so, not just mirroring as today) with Sculpt OS.
* Update of our Intel GPU work (done some years ago) and integrate with Sculpt OS, e.g. make it usable in a daily fashion.
* I really would like to move my daily developer load (edit/compile/link/run) out of a VM. This is possible since long time, but requires better integration with Sculpt and performance improvements on various edges.
* Extend easiness of writing multithreaded service/multiplexer components. In principle this is possible, but requires some love and extensions to minimize unnecessary cross CPU load.
* SMMU (read: I/O-MMU by ARM) in our own base-hw kernel.
Cheers,
Alex.
Hello Genodians,
a year is almost over and here are my two cents to the roadmap review and wish list. First, I want to say that I'm really proud about the accomplished technical work by Genode over the whole year. Getting Sculpt OS to the i.MX8 board with all the device drivers running is not given nor easy.
Before starting with the ideas for next year, I will review the input of me [0] and see how it was tackled:
The screen-casting topic developed a bit differently then I aspired, but it occupied me over the whole year over and over. On the one hand, in the beginning of the year, I was faced by streaming somehow Android to Genode, which resulted in the Scrcpy work eventually. It was really alien to me in the beginning, required to leave my comfort zone. Reading/understanding/extending an Android app and using Java I had done years back at University. On the other hand, this work also reinforced to me the motivation, not solely the pandemic, to record our demos and new features whenever possible. The Scrcpy work also strongly strengthen the believe that the CPU migration work, done in the second part of the year, is required for ported software. All in all, now I even do video editing, which was alien to me, and I already could support my fellow developers with that :-). Of course, the quality needs improvements but also requires more time. Let's see. Nevertheless, I see it as success - probably, we never uploaded more Genode related videos within one year ever [1][2][3][4].
Even so my envisioned [0] improved AMD support did not make it to the official roadmap, I invested some of my private spare time. The base is the base, and upholding isolation of mad going devices/drivers from the rest of the Genode OS components is crucial. This lead to the work of adding IO-MMU support for AMD machines to get to the same isolation level for device drivers as for the Intel machines. Testing this feature on all of the modern AMD machines of my friends and family took a while to get it done and straight. With an extended Sculpt 20.08 image at hand, I discovered and addressed several other issues, e.g. network and USB. Finally, I started to improve the VBox5 AMD support in my private spare time, which still needs some tweaks. My hope is, that with the next Sculpt OS release more AMD machines are usable actually.
Of course, also several smaller topics and clean up work through the whole Genode framework (e.g. replacing Genode lock with mutex/blockade) were part of the year.
For the next year, I would like to see progress in the following topics and I'm willing to work on them and/or contribute to:
* Extended desktop support using multiple monitors (so, not just mirroring as today) with Sculpt OS.
* Update of our Intel GPU work (done some years ago) and integrate with Sculpt OS, e.g. make it usable in a daily fashion.
* I really would like to move my daily developer load (edit/compile/link/run) out of a VM. This is possible since long time, but requires better integration with Sculpt and performance improvements on various edges.
* Extend easiness of writing multithreaded service/multiplexer components. In principle this is possible, but requires some love and extensions to minimize unnecessary cross CPU load.
* SMMU (read: I/O-MMU by ARM) in our own base-hw kernel.
Cheers,
Alex.
[0] https://lists.genode.org/pipermail/users/2020-January/007003.html [1] https://www.youtube.com/channel/UCondpn1UQ_TTNMVq3sbZLlg [2] https://www.youtube.com/channel/UCp32vvUpjfAh6D7yHJyGpAQ [3] https://www.youtube.com/user/Hyronimo1 [4] https://www.youtube.com/user/zero2nowhere
On 18.12.20 14:58, Norman Feske wrote:
Dear Genode community,
the end of the strange year 2020 comes in sight. So now it is time to kick off our annual road-map discussion. I'll keep up with our tradition of reviewing the past 12 months from my personal perspective, dropping my ideas for the upcoming year, and inviting you to share your ideas and plans.
Review of 2020
The overarching theme of our road map for 2020 was "Dwarfing the barrier of entry", which expressed the ambition to reach a wider audience. On that account, we identified four promising directions: First, making Sculpt OS palatable for a wider circle. Second, fostering the public perception of the high quality of Genode to reinforce the confidence of people who are sceptical towards novel operating-system technology. Third, lowering the barrier of entry by providing frictionless tooling. And fourth, publicly presenting use cases that prove the fitness and flexibility of Genode.
These directions certainly did a good job of motivating the working topics of this year's four releases [1,2,3,4].
[1] https://genode.org/documentation/release-notes/20.02 [2] https://genode.org/documentation/release-notes/20.05 [3] https://genode.org/documentation/release-notes/20.08 [4] https://genode.org/documentation/release-notes/20.11
The UI improvements of Sculpt OS in version 20.02 largely eliminated the need to use the command line, as shown in my live demo [5]. But the work on the user-visible side of Sculpt has admittedly dried up a bit since spring time. Software quality has been a continuous topic. Personally, I dedicated a lot of energy to the improvement and consolidation of our POSIX support (Noux vs. libc) and the related infrastructure like the VFS server.
[5] https://www.youtube.com/watch?v=vmgWgzeKAjU
That said, despite the many technical advances, the stated soft goal of reaching a broader audience remains fairly distant. Genode has not seen a significantly wider adoption by the open-source community at large compared to one year ago.
On the other hand, regarding our stated commitment to 64-bit ARM hardware, in particular supporting the NXP i.MX8 SoC, there is a strong sense of accomplishment, which makes me proud. The depth and breadth of this line of work has been fantastic. I'm speaking of 64-bit multi-core virtualization, HDMI, touch input, OLED, networking, LTE, USB, clock and power management, VirtIO, up to running Sculpt OS on this platform. It is a huge success story on a technical account.
Regarding our reach to a broader community, we are super excited about the prospect of combining Genode with the MNT-Reform laptop that is based on the i.MX8 SoC. When speaking of i.MX8 one year ago, I also had the Librem5 in mind - envisioning Genode on a smart-phone form factor. But that hope remained abstract as we did not succeed to establish a correspondence with the makers of the Librem5. The vision of a Genode-based smart phone, however, has become stronger than ever (see below).
While reading the paragraphs above, you may sense my ambiguous feelings about the past year's road map. I think we missed the stated goal. I also think that we excelled at technological progress. For us developers, the road map serves primarily as orientation for our technical work. But since the past year's goal of increasing adoption hasn't been a technical one, no level of technical excellence will magically bring us there. So the goal was a bit delusionally to begin with. Let us lift this pressure for the next year and concentrate on the technical level.
My personal ambitions for 2021
By the end of the year, I want to use a Genode-based mobile phone, replacing my current Nokia 3720. I'll focus on the _Pinephone_. In fact, I have already taken the first baby steps and will continue to thoroughly document this line of work at https://genodians.org.
I see plenty of opportunities for optimization throughout Genode and would like to make _optimization_ the motto of the year. The following ideas are spontaneously crossing my mind:
- Profiling and tuning of Unix-like workloads, in particular by looking at file-system access patterns.
- Fostering the batching of async I/O, e.g., increasing the chance for the batching of network packets.
- Let our ARM tool chain use the hard-float calling convention.
- Replace the allocator of our C runtime by jemalloc.
- Reducing the overhead of our POSIX TLS mechanism.
- Taking XML parsing off the critical path for the dynamic reconfiguration of init.
- Removing indirections, in particular the old libc plugin interface.
- Reducing the inflation of binaries by C++ templates.
- Improving compilation times by reducing header interdependencies.
- Merging core's CPU and PD service into one.
I'm convinced that we have to dramatically reduce the engineering effort needed to port device drivers from the Linux kernel to Genode. Backed by our practical DDE-Linux experience, a few ideas have formed in the back of my head. They want out. So I see my work with the Pinephone as a welcome opportunity for experimenting in this direction.
What's your perspective?
For drafting the road map of next year, I'm eagerly interested in the perspective of my fellow developers and of course users of Genode.
How do you perceive the outcome of the year?
What areas would you wish to concentrate on?
Where do you see untapped potential of Genode?
How do you envision Genode in December 2021?
I would very much appreciate your input for forming a rough picture of next year. Of course, not all ideas will make it to the road map. Economic constraints and the willingness of pro-active participation play a major role. Regarding the timeline, I plan to announce the official road map for 2021 in mid of January.
Cheers Norman
Hi Alex,
thanks for joining the discussion. I appreciate your review and thoughts!
Remembering that you suggested the load-balancing topic for the 2020 road map in the first place, it is particularly good to see how it got interwoven with the challenges that came with the Scrcpy topic. What a nice coincidence.
From my perspective, your series of articles and the accompanied video
captures were always fascinating to read/watch. They gave lively insights into otherwise very technical topics. I'd love to see you continuing to speak about your work in this way.
For the next year, I would like to see progress in the following topics and I'm willing to work on them and/or contribute to:
Extended desktop support using multiple monitors (so, not just mirroring as today) with Sculpt OS.
Update of our Intel GPU work (done some years ago) and integrate with Sculpt OS, e.g. make it usable in a daily fashion.
I really would like to move my daily developer load (edit/compile/link/run) out of a VM. This is possible since long time, but requires better integration with Sculpt and performance improvements on various edges.
Extend easiness of writing multithreaded service/multiplexer components. In principle this is possible, but requires some love and extensions to minimize unnecessary cross CPU load.
SMMU (read: I/O-MMU by ARM) in our own base-hw kernel.
These are all important topics. They certainly deserve to be on the road map.
It's good to see your interest even in unexpected areas such as the GPU work. Your point about the developer load seems perfectly in line with the optimization theme I suggested.
Of your topics, the multi-head topic is certainly the most vague. At the driver side, I see what to do. But the topic will have to touch the entire GUI stack (drivers, nitpicker, window management, dpi considerations, configuration interfaces, Sculpt). Given the wide scope, I sense that we ultimately need to define intermediate goals.
Cheers Norman
Hello everyone,
annual discussion about roadmap has been started a little earlier than last year and that forces me to say a little about my current work around Genode which is not yet ready to be published (possibly I need a week or two). More about it later in summary of current year and my plans for next one.
Summary of current year
In my roadmap for 2020 I stated two areas in which I'm going to work. First was continuing work for supporting different rpi devices. Unfortunately this work did not progress much as the blocker issue with usb handling is still unresolved. At some point in time I felt powerless and left it. At least until now noone else had motivation to fight with it so this work is stalled.
Another direction was to try to setup a working environment for Genode development in some IDE - possibly in Eclipse. I started some work in this direction and quickly found out that to be able to configure some kind of project with which IDE will be able to help with programming I need to provide to it as much information about build as possible especially source files, include paths, compilation flags. Without this information even features like syntax highlighting and identifiers completion cannot work. So I started to look into internals of Genode build system to find a way to extract those informations.
During this process once again I realized why I don't like build system based on make and especially after I found out that recursive make in case of Genode build system can be written with capitalized "R" in recursive :-). Maybe I'm just incompatible with make but trying to understand details of it was so hard for me, that one more time I started thinking if it would be possible have this build system implemented/converted to scons, in what ways it would be better and what would be worse.
Sidenote: During last Hack'n'Hike in 2019 we had a discussion about scons and make and that decision was made to use make. I also read a paper about comparison of make and scons for Genode and I don't really know what concrete elements/features were that the decision was to choose make.
In consequence I started my own project to create a scons based build system for Genode. My plan was to create one and use it myself for rpi development, fix all issues that I really dislike about current build and verify if there are some problems that I don't see that would reject the whole idea. Given the simplicity of most of makefiles in Genode I did not expect that this small part will be complex enough that implementation will take me half of the year.
The most important things I do not like in current build system are:
* big recompilations after touching makefiles and after switching branches
* cases when leftovers in build directory caused hard to diagnose build problems
* lack of easy ways to debug what is going on inside make (or maybe it's just my inability to comprehend it)
My main goals were:
* implement build in a way that would be able to use current build description with as little changes in Genode repository as possible (currently only two symlinks have to be created and one "marker" file in each build directory to specify that this build directory is built with scons)
* implement a verification mechanisms to be sure that scons build is 100% correct replacement of current build (I build database of commands from both types of build and compare them list of targets and that commands are identical - after some normalization)
* remove all absolute paths in compilation commands - they are used for all paths in current build - and they are bad for reproducible builds (which should be a goal for a project at some point in time), bad for using ccache or similar tools and bad for defining a project in IDE
* be able to understand and retrieve all informations about build to be able to use it in external tools ide and possibly other like static analyzers
Current state and missing parts:
* above goals are achieved for build of almost all target on linux build on sources from release 20.08 with repositories enabled by default (base, base-linux, os, demo). First attempts for arm6 shown only some minor inconsistencies in command flags so it should quickly go forward
* missing any installation and usage documentation
* need to verify on 20.11 release and current master
I hope to finish those parts quickly and make it public this year.
Plans for next year
I plan to further develop build system based on scons at least until it fullfills my own whishes about it or until I find some blocker that I won't be able to overcome. As originally I plan to use it for development for rpi. I know that I'll have to add some support for ports (I plan only wrapper for current descriptions), depots and possibly something more.
Depending on results of this experiment and reception of Genode team and community I will throw it away, use it myself or maybe develop further features and fixes - I'm curious how it will be.
On the rpi front I still plan to work on it. I plan some work on rpi4 (which is not affected by current usb blocker) and hopefully other variants too.
Comment on Norman's plans
All of your plans are really great.
Plan on supporting PinePhone is definitely appealing for broader audience. I'll probably buy one in case of success and see how it works.
Optimization attempts also seem to be a great target. Improving efficiency will probably further improve code quality and will require more tooling that will allow to constantly test for more kinds of regresssions - especially those related to efficiency.
But for me ideas around impremovements of DDE seem to be most interesting. Especially that I had my own ideas that I queued to explore for myself. During driver porting attempts I felt that amount of code that has to be duplicated (even though it was just dummy stubs) was too big. If I refresh this knowledge during work on rpi I'll definitely like to participate in discussion about it. Porting device drivers from Linux seem to me a very important aspect.
Regards Tomasz Gajewski
Hi Tomasz,
thank you very much for your elaborate posting. Your insightful reflections are an interesting read.
In my roadmap for 2020 I stated two areas in which I'm going to work. First was continuing work for supporting different rpi devices. Unfortunately this work did not progress much as the blocker issue with usb handling is still unresolved. At some point in time I felt powerless and left it. At least until now noone else had motivation to fight with it so this work is stalled.
Even though there was a brief period of activity when Stefan made some progress, the topic [1] became stale again. I understand the slip of motivation. Even though I have enabled the Rpi (including working USB) originally, I would not consider picking it up again in my spare time. I'm sorry that the support from our side was insufficient for you to carry on. Unfortunately, I doubt that 2021 will look much different.
[1] https://github.com/genodelabs/genode/issues/3247
During this process once again I realized why I don't like build system based on make and especially after I found out that recursive make in case of Genode build system can be written with capitalized "R" in recursive :-).
Please let me address the statement regarding "recursive make" in Genode.
What is commonly referred to as a unholy practice "recursive make" is the use of Makefiles scattered throughout a directory structure where the Makefile of the parent directory triggers the Makefiles of the child directories. Genode's build system does not do that. The instances of make spawned by the build system serves different and orthogonal purposes.
- The frontend (Makefile in the build directory) consumes the build configuration and triggers lib-dependency stage, the builds, and the invocation of run scripts.
- The library-dependency stage traverses target description files without building anythin, to construct a library-dependency graph. This could strictly be taken as an example of "recursive make" if we decided to split hairs.
- Orchestration of the library and target builds (executing the library-dependency graph, which happens to be a Makefile).
- Library build, building a single library.
- Target build, building a single target.
If you add the depot tools to the picture, this story continues because the depot tools are, well, based on make and invoke Genode's make-based build system.
So yes, Genode relies on make in a nested fashion. But it does not operate in the way commonly described as "Recursive Make Considered Harmful".
Maybe I'm just incompatible with make but trying to understand details of it was so hard for me, that one more time I started thinking if it would be possible have this build system implemented/converted to scons, in what ways it would be better and what would be worse.
It has to come down to different tastes. Build systems - like programming languages, coding styles, and editors - tend to invoke emotional responses in programmers. After all, the personal background, familiarity, aesthetic sense vary from person to person.
I'm not in the position to question anyone's taste. But I feel very strongly about consistency. In my (strong) opinion, the true mastering of a few orthogonal tools is preferable to large tool box of casually used tools. It takes time to reach the level of craftsmanship with a tool. Even though I repulsed against make for a long time, I once took the deliberate decision to *embrace* it despite its shortcomings. Since I embraced it, I had a chance to master it, and now I apply it consistently and happily.
It is not unreasonable to prefer Scons over Make, or Python over Tcl, or JSON over XML. But regardless of the quality of a tool, adding a non-orthogonal tool to the toolbox spoils the consistency of the whole unless the new tool replaces an existing tool completely. I don't see that coming in the case of make for Genode.
The current tool set of Coreutils, Make, Tcl, XML, C++ may not be perfect. But we apply them consistently and competently. To justify the huge investment of retraining our tool proficiency towards the consistent use of Python replacing make, there ought to be hard business arguments.
Please don't take the words above critique. I admire that you actually implement the improvements, instead of solely expressing your discomfort with Genode's tools. I just hope that you won't be let down by me not sharing your enthusiasm with switching away from make for Genode's build system.
In consequence I started my own project to create a scons based build system for Genode. My plan was to create one and use it myself for rpi development, fix all issues that I really dislike about current build and verify if there are some problems that I don't see that would reject the whole idea. Given the simplicity of most of makefiles in Genode I did not expect that this small part will be complex enough that implementation will take me half of the year.
The most important things I do not like in current build system are:
- big recompilations after touching makefiles and after switching branches
I have to admit that my use of ccache made me blind to see this pain point. We completely missed to cover ccache in our documentation. It may be worthwhile to streamline the use of ccache with Genode's build system similar to how one can enable parallel builds in the build.conf file.
- cases when leftovers in build directory caused hard to diagnose build problems
I sometimes hit this problem, in particular when moving header files around. It is inherent to the use of dependency files. Scons notably goes a different way.
In practice, I would not dramatize these corner cases. In relation to the developer time sunk into all kinds of other issues, I perceive it a negligible inconvenience.
- lack of easy ways to debug what is going on inside make (or maybe it's just my inability to comprehend it)
Make is a can of worms, no question. Please excuse my polemics, but this argument can go towards all kinds of power tools [2]. ;-)
[2] https://github.com/satwikkansal/wtfpython
My main goals were:
implement build in a way that would be able to use current build description with as little changes in Genode repository as possible (currently only two symlinks have to be created and one "marker" file in each build directory to specify that this build directory is built with scons)
implement a verification mechanisms to be sure that scons build is 100% correct replacement of current build (I build database of commands from both types of build and compare them list of targets and that commands are identical - after some normalization)
remove all absolute paths in compilation commands - they are used for all paths in current build - and they are bad for reproducible builds (which should be a goal for a project at some point in time), bad for using ccache or similar tools and bad for defining a project in IDE
be able to understand and retrieve all informations about build to be able to use it in external tools ide and possibly other like static analyzers
If I understand these points correctly, you are actually not after replacing Genode's build system but rather supplementing scons as another option? That would side-step the friction I feared, which would be pretty cool.
Current state and missing parts:
above goals are achieved for build of almost all target on linux build on sources from release 20.08 with repositories enabled by default (base, base-linux, os, demo). First attempts for arm6 shown only some minor inconsistencies in command flags so it should quickly go forward
missing any installation and usage documentation
need to verify on 20.11 release and current master
I hope to finish those parts quickly and make it public this year.
I'm looking forward to try it out.
Plans for next year
I plan to further develop build system based on scons at least until it fullfills my own whishes about it or until I find some blocker that I won't be able to overcome. As originally I plan to use it for development for rpi. I know that I'll have to add some support for ports (I plan only wrapper for current descriptions), depots and possibly something more.
I wonder, have you considered adding scons support to the Goa tool [3]? Goa is completely independent from Genode's build system and already supports make, cmake, autoconf, and qmake.
[3] https://github.com/nfeske/goa
Depending on results of this experiment and reception of Genode team and community I will throw it away, use it myself or maybe develop further features and fixes - I'm curious how it will be.
On the rpi front I still plan to work on it. I plan some work on rpi4 (which is not affected by current usb blocker) and hopefully other variants too.
Thanks for sharing these plans. Let's cross fingers about USB on rpi4.
Comment on Norman's plans
All of your plans are really great.
Plan on supporting PinePhone is definitely appealing for broader audience. I'll probably buy one in case of success and see how it works.
Optimization attempts also seem to be a great target. Improving efficiency will probably further improve code quality and will require more tooling that will allow to constantly test for more kinds of regresssions - especially those related to efficiency.
But for me ideas around impremovements of DDE seem to be most interesting. Especially that I had my own ideas that I queued to explore for myself. During driver porting attempts I felt that amount of code that has to be duplicated (even though it was just dummy stubs) was too big. If I refresh this knowledge during work on rpi I'll definitely like to participate in discussion about it. Porting device drivers from Linux seem to me a very important aspect.
I'm happy to see your resonance to my plans. It's especially cool that you want to join the DDE-Linux line of work!
Cheers Norman
Norman Feske norman.feske@genode-labs.com writes:
Even though there was a brief period of activity when Stefan made some progress, the topic [1] became stale again. I understand the slip of motivation. Even though I have enabled the Rpi (including working USB) originally, I would not consider picking it up again in my spare time. I'm sorry that the support from our side was insufficient for you to carry on. Unfortunately, I doubt that 2021 will look much different.
I know the situation. And issue number looks familiar to me :-)
During this process once again I realized why I don't like build system based on make and especially after I found out that recursive make in case of Genode build system can be written with capitalized "R" in recursive :-).
Please let me address the statement regarding "recursive make" in Genode.
What is commonly referred to as a unholy practice "recursive make" is the use of Makefiles scattered throughout a directory structure where the Makefile of the parent directory triggers the Makefiles of the child directories. Genode's build system does not do that. The instances of make spawned by the build system serves different and orthogonal purposes.
The frontend (Makefile in the build directory) consumes the build configuration and triggers lib-dependency stage, the builds, and the invocation of run scripts.
The library-dependency stage traverses target description files without building anythin, to construct a library-dependency graph. This could strictly be taken as an example of "recursive make" if we decided to split hairs.
Orchestration of the library and target builds (executing the library-dependency graph, which happens to be a Makefile).
Library build, building a single library.
Target build, building a single target.
Thank you for this description (although I already gathered knowledge about this part). Adding run tool to this picture makes this picture a little more "recursive" :-). Actually removing recursive interplay between the run tool and build system is something I'd like to remove but I don't know how and this will be a topic for discussion later.
If you add the depot tools to the picture, this story continues because the depot tools are, well, based on make and invoke Genode's make-based build system.
I assume that it is similar to case with run tool but I'll know when I get to it.
Make is a can of worms, no question. Please excuse my polemics, but this argument can go towards all kinds of power tools [2]. ;-)
I'll definitely read it. It looks very interesting.
If I understand these points correctly, you are actually not after replacing Genode's build system but rather supplementing scons as another option? That would side-step the friction I feared, which would be pretty cool.
Generally roadmap is not a good place to actually anounce and discuss it but I was kind of forced to do it here.
Generally I really, really like the consistency of definitions of libraries and programs in Genode and my idea is to make it even more strict with scons. After I release some initial version I'll start discussion about some issues I found. But for a start - were you aware that current build system forgives errors like in [1] :-)
https://github.com/genodelabs/genode/blob/master/repos/base-linux/src/test/l...
I hope to finish those parts quickly and make it public this year.
I'm looking forward to try it out.
Great.
Plans for next year
I plan to further develop build system based on scons at least until it fullfills my own whishes about it or until I find some blocker that I won't be able to overcome. As originally I plan to use it for development for rpi. I know that I'll have to add some support for ports (I plan only wrapper for current descriptions), depots and possibly something more.
I wonder, have you considered adding scons support to the Goa tool [3]? Goa is completely independent from Genode's build system and already supports make, cmake, autoconf, and qmake.
I did not look at this tool yet. Using it to port something is in my personal work queue and maybe then some extension ideas will come.
Cheers Tomasz
On 12/18/20 8:58 AM, Norman Feske wrote:
Dear Genode community,
the end of the strange year 2020 comes in sight. So now it is time to kick off our annual road-map discussion. I'll keep up with our tradition of reviewing the past 12 months from my personal perspective, dropping my ideas for the upcoming year, and inviting you to share your ideas and plans.
First of all, I'd like to thank everyone on the Genode team, and all you other developers out there, for another year of excellent progress!
[snip]
What's your perspective?
For drafting the road map of next year, I'm eagerly interested in the perspective of my fellow developers and of course users of Genode.
How do you perceive the outcome of the year?
I completely agree with your assessment of the year. The technical progress was impressive as always, across the entire spectrum of the ecosystem (build tools, platforms, drivers, API refactoring, etc.)!
As to growing the community, who knows what it takes to get some attention in this world?! It'll probably go viral when we're least expecting it. ;^)
Personally, I am very disappointed at the small amount of time that 2020 allowed me to spend on Genode. Here's hoping 2021 is much better!
What areas would you wish to concentrate on?
As a user, my #1 priority for 2021 is to set up Sculpt as a "daily driver" on my ThinkPad convertible. (I will be asking for advice on this topic in a separate message.)
As a developer, I greatly appreciate (and admire) the work of those porting software, but my personal passion is to exploit the unique potential of the native Genode API, both for reducing the TCB and also exploring elegant ideas that are not possible on other platforms.
There are obviously many areas to focus on (too many for one person!), but a couple that leap off the page for me are: 1) seeing what creative ideas the VFS system might support, and 2) using the Nitpicker UI to create low-TCB front-ends. I would also like to play more with writing Ada/SPARK components.
I have some other dreams too, but I'll keep them to myself until I have something more concrete to contribute. ;^)
Oh yes, if I do get any free time, I would also like to update "Genode Corner", and turn it into a useful resource.
Where do you see untapped potential of Genode?
Everything! Seriously, everything from boring-but-useful low-TCB server appliances, through standard desktops, to secure mobile platforms - all are within reach.
On the topic of mobile, I also am very excited about this use case! (Add me to the list of people who will buy a PinePhone if/when your port gets to a certain level.)
Personally, I am more interested in tablet features than phone features, for two reasons: 1) it is a quicker path to a useful device, since the proprietary phone-specific parts seem to always be a problem, and 2) for added security, I don't mind using a tablet connected via WiFi and/or Bluetooth to a phone/hotspot.
As you develop this, if you want to throw some mobile/tablet UI POCs out there, I will be happy to test them on the ThinkPad!
How do you envision Genode in December 2021?
As my daily driver desktop, for one thing! If you keep going on the path you are on with Leitzentrale, moving more common actions into the UI, I really think it can gain traction.
One last wish, if I may: to have Spunky promoted to a first-class kernel. :^)
Thanks!
John J. Karcher devuser@alternateapproach.com
Hi John,
thank you for the enthusiastic feedback. :-)
There are obviously many areas to focus on (too many for one person!), but a couple that leap off the page for me are: 1) seeing what creative ideas the VFS system might support, and 2) using the Nitpicker UI to create low-TCB front-ends. I would also like to play more with writing Ada/SPARK components.
I have some other dreams too, but I'll keep them to myself until I have something more concrete to contribute. ;^)
Oh yes, if I do get any free time, I would also like to update "Genode Corner", and turn it into a useful resource.
Great to know that you consider picking up the work on the Genode Corner.
Cheers Norman
Hi Genodians,
Thanks Norman for the Roadmap reminder! And thanks to you and all the other community members for your detailed insight in your very motivating plans!
I'll have a try:
Review 2020 ===========
Kernels ~~~~~~~
* Spunky kernel written entirely in Ada * Spunky kernel SPARK compliance * Let further Genode core functionality benefit from Ada/SPARK
I was able to work at this a lot at the beginning of the year, resulting in a presentation and demonstration at FOSDEM 2020 in February [8][10]. The RPC, Signalling, CPU Scheduling, Data Structures and a good part of the Clock of Spunky made it to Ada [9][11]. Also the Sculpt OS is running smoothly with the kernel [10]. Unfortunately from that point on other projects consumed most of my time and I had to postpone the "Ada-for-core" project again and again. However, I'm still motivated to continue with this project as soon as possible.
Block encryption ~~~~~~~~~~~~~~~~
* Towards using the Consistent Block Encrypter (CBE) on a daily basis
Unexpectedly, this project consumed most of my time this year. We did a complete rework of the internal CBE design and added a lot of functionality: Online rekeying [1][7], online resizing [2][7], a trust anchor API and a trust anchor reference implementation [3], a comprehensive scriptable test environment [3], a VFS integration of the CBE and of each of its back ends [3][7], and a fancy demo featuring a Linux VM on a CBE device in Sculpt [4][5][7].
As a side effect of the project, we also extended our Ada/SPARK runtime support and established an Ada/SPARK coding style [6].
Network stack ~~~~~~~~~~~~~
* Design review of the NIC router
Although this is an important topic, other issues with the NIC router and networking in Genode in general turned out to be more important for now.
* NIC router functionality
There were several smaller features missing with the NIC router. We could add advanced means of forwarding DNS server addresses with the NIC router, add support for ARP-less domains, and consolidate the link state propagation.
* Turn NIC drivers into Uplink session clients
This work is part of our project "restartable NIC drivers" and it is still in progress, but almost all NIC drivers are already adapted and I'm positive that we'll have restartable NIC drivers in the next Sculpt release.
Hardware support ~~~~~~~~~~~~~~~~
* initializing Intel Hardware P-States (HWP)
My new Lenovo T490 motivated me to do something about supporting Intel HWP and although it took some time, it turned out well, hopefully not only to my own benefit [12]
Timing stack ~~~~~~~~~~~~
* Clean up Timeout framework * Consolidate multithreading support in timeout framework
These also turned out to require some time. Especially the testing and debugging afterwards. But now there are new automated tests that demonstrate that multithreading works well and the framework could also be significantly simplified. Was worth it.
My plans so far for 2021 ========================
* Finish making NIC drivers restartable in Sculpt
* Establish new API for network sessions (NIC, Uplink) inspired by the modern Block-Request APIs in order to simplify the use of network sessions and eliminate corner cases
* Graphical front end and simpler integration in general for the Consistent Block Encrypter in Sculpt
* Write a comprehensive CBE documentation
* Revive the Spunky project and bring it into Genode mainline
* Enhance Ada/SPARK runtime support and use Ada/SPARK for further fundamental code
Cheers, Martin
[1] http://genodians.org/m-stein/2020-06-07-cbe-rekeying [2] http://genodians.org/m-stein/2020-06-07-cbe-rekeying [3] https://genode.org/documentation/release-notes/20.08#Consistent_Block_Encryp... [4] https://genode.org/documentation/release-notes/index [5] https://genodians.org/m-stein/2020-06-17-cbe-linux-vm-video [6] https://genode.org/documentation/release-notes/20.08#Ada_SPARK_support [7] https://genode.org/documentation/release-notes/20.05#Feature-completeness_of... [8] https://archive.fosdem.org/2020/schedule/event/ada_spunky/ [9] https://genodians.org/m-stein/2019-05-09-spunky-1 [10] https://genodians.org/m-stein/2020-02-03-spunky-3 [11] http://genodians.org/m-stein/2019-12-20-spunky-2 [12] https://genode.org/documentation/release-notes/20.11#Hardware_P-State_suppor...
Hi Martin,
it is fascinating to see all those areas of your work in review. I'm very grateful that you took the block-encryption topic under your wings. Now I am as eager as you to see it become a natural part of Sculpt, similar to how we enjoy the NIC router today.
My plans so far for 2021
Finish making NIC drivers restartable in Sculpt
Establish new API for network sessions (NIC, Uplink) inspired by the
modern Block-Request APIs in order to simplify the use of network sessions and eliminate corner cases
- Graphical front end and simpler integration in general for the
Consistent Block Encrypter in Sculpt
Write a comprehensive CBE documentation
Revive the Spunky project and bring it into Genode mainline
Enhance Ada/SPARK runtime support and use Ada/SPARK for further
fundamental code
I find all those points worthwhile to pursue. Regarding the Ada/SPARK direction, I sense that we'll need to ways to infect more Genodians with it. Personally, after a brief stint, I haven't managed to keep up with it unfortunately.
Independently from the roadmap discussion, I would appreciate the brainstorming of areas where Ada/SPARK would be naturally applicable in Genode. E.g., with CBE we use Ada/SPARK as a core of a VFS plugin. Maybe this could be generalized such that this language becomes a go-to choice for implementing other parts of the storage stack (file system, cache)?
Cheers Norman
Dear Genode community,
thank you Norman for initiating the roadmap debate again, and for sharing your thoughts. Here is my input to it.
On Fri, Dec 18, 2020 at 02:58:49PM +0100, Norman Feske wrote:
What's your perspective?
For drafting the road map of next year, I'm eagerly interested in the perspective of my fellow developers and of course users of Genode.
How do you perceive the outcome of the year?
I agree with your perception that we did not achieved to reach a new, wide audience for Genode topics. Anyway, I see signs for a slowly, but consistently growing ecosystem around Genode in the shape of new, and remained users, and companies docking to our development steadily. And I think the steps done, regarding ARM64 development in this year in general, and around the i.MX8MQ SoC in particular, leverage Genode's potential for an increasing community.
Personally, I'm a bit disappointed by myself, because I was dead set on enabling Sculpt OS on the MNT Reform 2 by the end of the year. But although it is almost done, I have not finished yet due to some hardware, and driver issues. Anyway, I'm keen to catch up.
What areas would you wish to concentrate on?
To me the further development of Genode/Sculpt as desktop OS on ARM machines stays in focus. Thereby, I see lots of overlaps with Norman's plans regarding Genode on a mobile phone, aka pinephone.
Technically, the biggest issue to me is still the driver ecosystem. Hereby, we already discussed (offline) alternative approaches for cheaper Linux device driver ports, which I would like to follow.
The further marriage of the x86 and ARM driver ecosystem is another heartfelt wish of me. Hereby, the coalescense of the platform driver API of both architectures is essential, which I would like to implement.
Beside the extension of the ARM VMM to use it for my productive daily development VM on the MNT Reform, I really would like to use mutt mail setup on Genode finally.
Where do you see untapped potential of Genode?
I still see Genode's resilience aspect as its biggest potential that is nevertheless not yet fully achieved. A system with solid core/init and resource multiplexers, no resource exhaustion, with restartable drivers, which can live as long as the hardware without the need to reboot. I think we are much closer to achieve that now.
How do you envision Genode in December 2021?
Well, using the MNT Reform 2 with one hand, while holding the Pinephone in the other hand - both systems running Genode in a technically mature form to handle my daily routine. That would be more than I can dream of technically-wise.
Best regards Stefan
Hi Stefan,
thank you for sharing your perspective, which happens to be perfectly aligned with my original posting.
I agree with your perception that we did not achieved to reach a new, wide audience for Genode topics. Anyway, I see signs for a slowly, but consistently growing ecosystem around Genode in the shape of new, and remained users, and companies docking to our development steadily. And I think the steps done, regarding ARM64 development in this year in general, and around the i.MX8MQ SoC in particular, leverage Genode's potential for an increasing community.
The participation and enthusiasm shown in this roadmap thread nicely underlines what you just said. :-) So I'm all fine with further nurturing our small and pleasant community.
Technically, the biggest issue to me is still the driver ecosystem. Hereby, we already discussed (offline) alternative approaches for cheaper Linux device driver ports, which I would like to follow.
The further marriage of the x86 and ARM driver ecosystem is another heartfelt wish of me. Hereby, the coalescense of the platform driver API of both architectures is essential, which I would like to implement.
Beside the extension of the ARM VMM to use it for my productive daily development VM on the MNT Reform, I really would like to use mutt mail setup on Genode finally.
The Linux driver topic makes a recurring appearance. I'm happy about this resonance. The more developers getting involved in the topic, the better.
The platform-driver topic is not glamourous but very important. Thank you for your willingness to continue this line of work.
Well, using the MNT Reform 2 with one hand, while holding the Pinephone in the other hand - both systems running Genode in a technically mature form to handle my daily routine. That would be more than I can dream of technically-wise.
What a nice picture you're putting in my head!
Cheers Norman
Dear Genodians,
first (as each X-mas in the past years) thanks to Norman for opening the roadmap discussion with a thorough reflection of activities and achievements of 2020.
On Fri, Dec 18, 2020 at 14:58:49 CET, Norman Feske wrote:
How do you perceive the outcome of the year?
Looking at my rough personal plans from 12 months ago I get mixed feelings. First, the network appliance topic again experienced very little attention. While I approached it from a new angle making some progress with the uacme client for Genodians.org and the OpenSSL update until May, the work remained on a topic branch and I got entirely occupied by other tasks up to now. It seems I need a different strategy for 2021 but seem to lack a plan yet.
The other topics I identified end of 2019 give a more positive picture, especially because of the excellent efforts of my fellow Genode developers. There's still demand for more work in following fields.
- Complete LibC thread safety
We worked hard on the robustness of the LibC runtime and multi-threaded networking in particular since 20.05 and made quite good progress. But the recent issue [1] and the still open [2] indicate demand for more attention. In this regard I still see the requirement for improved "Continuous POSIX-compliance testing".
[1] https://github.com/genodelabs/genode/issues/3969#issuecomment-748146578 [2] https://github.com/genodelabs/genode/issues/725
- Cultivation of Goa as porting environment
With uacme I started my first port based on the Goa tool and the first steps where pretty promising. I'd love to see more applications finding their path to Genode on account of this tool.
What areas would you wish to concentrate on?
I struggle to draft my future Genode developments as the past showed I'm prone to wrong forecasts in this regard. My role seems to be more in filling gaps on demand and helping out. I'd love to add my share to accomplish a nice and tidy Genode phone though.
But beyond that, I expect to continue my intensive work on VirtualBox in all facets, may it be features, optimizations, or breaking new grounds with support for efficient guest graphics. Also definitely on the list is the integration of uacme into Genodians.org.
I'm looking forward to another exciting Genode year.
Regards
Hi Genodians,
Norman Feske (18.12.20, 14:58): What's your perspective? What areas would you wish to concentrate on?
Seems I will get the chance to spend more time on Genode in general and understanding better how to use it. Especially when it comes to RISC-V and seL4. So, I'm really looking forward to this.
Axel
--- Civilization is just a temporary failure of entropy.
Hi Axel,
On 23.12.20 06:25, Axel Heider wrote:
Seems I will get the chance to spend more time on Genode in general and understanding better how to use it. Especially when it comes to RISC-V and seL4. So, I'm really looking forward to this.
thank you for chiming in!
Admittedly, both seL4 and RISC-V have not received much attention from our side in 2020. I very much welcome to revive these topics.
Regarding seL4 in 2021, bringing Genode in line with the current kernel version and the MCS scheduling comes in mind first. Furthermore, to make Genode fit into seL4's often lauded "verification story", we may contemplate combining Genode with CAmkES, to the benefit of both communities.
Your involvement is very welcome and motivating.
Cheers Norman
Dear Genodians,
Looking back on this crazy year, it is again impressive what the Genode community achieved. Ranging from ARMv8 support, over to the vastly improved libc, its thread safety, and then Martin's Consistent Block Encrypter (CBE)... Regarding the width of the audience, I believe one major aspect for the success of the Genode project is to be able to run existing code as easily as possible. Norman's Goa tool seems quite promising! In this regard, I want to thank Alexander Tormasov for initiating Go support for Genode. Can't wait to try it out!
Personally, I finished the named pipe feature of the vfs/pipe plugin to my liking [1]. The main motivation behind it was to easily stream data from pure Genode components to libc components via file-system sessions that can be attached to stdin, stdout and stderr. This feature also makes it possible to pipe several components together similarly to how it is possible on unix.
[1] https://github.com/genodelabs/genode/issues/3583
What areas would you wish to concentrate on?
I'm interested in platform integrity. So, I'm looking forward to trying out the CBE features and maybe using a TPM as trust-anchor. As with the improved AMD support by Alexander Boettcher, I would like to investigate using its RAM encryption technique (AMD SEV). I also really like the idea of Johannes to bring tracing tools like Lttng to Genode.
Where do you see untapped potential of Genode?
I share Stefan Kalkowski's view on Genode's resilience aspect as its biggest potential. Additional to the resiliency of the system architecture as a whole, I see potential in the stability of the libc runtime. Further, exposing the hard real-time capabilities from (some) kernels to the Genode user-land would open up new possibilities as well.
How do you envision Genode in December 2021?
* A stable libc runtime that makes it easy and safe to port existing C/C++ code * Go support * Performance improvements regarding networking * Extended ARMv8 support, namely IOMMU protection
Yours truly, Sid
Hi Sid,
thank you for presenting your review of the past year and your outlook for 2021.
Personally, I finished the named pipe feature of the vfs/pipe plugin to my liking [1]. The main motivation behind it was to easily stream data from pure Genode components to libc components via file-system sessions that can be attached to stdin, stdout and stderr. This feature also makes it possible to pipe several components together similarly to how it is possible on unix.
I think this mechanism has a lot of potential. E.g., for simplifying scenarios like the ssh-exec server.
Since you linked the issue, would now be a good time for a wrap-up, considering the feature for staging?
Where do you see untapped potential of Genode?
I share Stefan Kalkowski's view on Genode's resilience aspect as its biggest potential. Additional to the resiliency of the system architecture as a whole, I see potential in the stability of the libc runtime. Further, exposing the hard real-time capabilities from (some) kernels to the Genode user-land would open up new possibilities as well.
I agree. We should definitely keep up with the continuous work on the libc edge cases. At times, your use cases - especially combining networking and pthreads - presented really hard nuts to crack, but it was all worthwhile. ;-)
How do you envision Genode in December 2021?
- A stable libc runtime that makes it easy and safe to port existing
C/C++ code
- Go support
- Performance improvements regarding networking
- Extended ARMv8 support, namely IOMMU protection
From my perspective, it is exciting to see your commitment to the Go
support. I'm curious how this story continues.
How do you feel about mentioning this topic on the official road map? Can you foresee which Genode version would be a realistic goal for this feature?
Cheers Norman
Hi Norman,
I think this mechanism has a lot of potential. E.g., for simplifying scenarios like the ssh-exec server.
Since you linked the issue, would now be a good time for a wrap-up, considering the feature for staging?
Thank you. I share your view on the potential of this feature. Yes, now is a good time to wrap-up this feature for staging. We can move the discussion the github issue.
From my perspective, it is exciting to see your commitment to the Go support. I'm curious how this story continues.
How do you feel about mentioning this topic on the official road map?
That would be great!
Can you foresee which Genode version would be a realistic goal for this feature?
My teammates Sergey Platonov, Stefan Thöni and Pirmin Duss are currently getting their hands dirty by investigating how much effort the Go support really is. It's not so trivial to estimate. I will keep you posted. It would be awesome if we could join forces for this endeavor!
Cheers, Sid
Hello,
my main work topic of 2020 has been porting QtWebEngine and the Falkon web browser to Genode, which also involved the move to building everything Qt with qmake and making it possible to build Qt applications with the Goa tool. The current state of the web browser is already quite usable, although some desired features like server certificate validation or audio/video support are still missing. That's something I intend to continue working on in 2021.
Apart from that, I'm also interested in the whole PinePhone topic in general and in particular the previously mentioned idea of exploring the possibilities of porting QML-based Sailfish OS or Ubuntu Touch applications and making it possible to build those with Goa.
Christian
Just a quick note...
I know I'm not alone in always enjoying the Genodians.org articles by the Genode devs. Please keep them coming!
But after reading all the interesting ideas (RISC OS, Haiku, IDE integration, RISC-V, hardware ports, software ports, etc., etc.), I would just like to encourage all of you to share your progress / discoveries with the rest of us (whether here, on Genodians, on Reddit, or wherever you choose).
If I do anything noteworthy, I will do likewise. ;^)
Happy New Year!
John J. Karcher devuser@alternateapproach.com
Hello fellow Genodians,
TL;DR the better part of the last year I worked on the CBE, while doing some driver refactoring (NVMe and PCI Audio) in between. Some things I originally planned to work on, namely USB Audio support and a lwext4 VFS-plugin, got somewhat side-lined. But I could dig up my old OSSv3 PoC and eventually was able to use cmus on Sculpt, which is nice.
So, on one hand this year I plan to tackle the things left over from last year. On the other hand, I would like to join the “iMX8 effort” by working on GPU/VPU support.
Regards Josef
Hi folks,
my main topics for 2020 have been Android pass through support on iMX8, touch screen and OLED display drivers for the same platform, as well as LTE modem support for Genode. Last year Genode made great progress where I especially want to mention the WebEngine and the Falcon Browser as one of many stand out topics. All in all it is nice to see how Genode grows more mature with every year and how our insights and knowledge in so many areas advance. After all, Genode is just a very small company. People tend to forget that.
For 2021 I want to resume our GPU line of work by starting with the update of the Mesa library and getting it running on ARM. Audio is another topic that I want to finally toggle, where any help/input from experienced developers in this field would be very appreciated. Additionally I recently started to update our RISC-V support to privileged ISA spec 1.10 and currently plan to remove the Spike emulator and replace it with Qemu. Many things may come along the way, the Pine64 is also a very cool project for example and I want to experiment with GOA since it seems to be a cool approach to porting 3rd party software to Genode.
Regards,
Sebastian
On 1/4/21 11:33 AM, Sebastian Sumpf wrote:
Hi folks,
my main topics for 2020 have been Android pass through support on iMX8, touch screen and OLED display drivers for the same platform, as well as LTE modem support for Genode.
This reminds me of something I meant to ask about when you posted your Genodians article on adding ARM touchscreen support: What would be involved with bringing touchscreen support to the PC platform?
I don't know if anyone is familiar with the interface(s) for active pens, which would be the icing on the cake, but it would be really nice to be able to test whatever touch UIs are developed for phones/tablets on the laptop as well.
Thanks!
John J. Karcher devuser@alternateapproach.com
Hello,
On 04.01.21 22:47, John J. Karcher wrote:
On 1/4/21 11:33 AM, Sebastian Sumpf wrote:
Hi folks,
my main topics for 2020 have been Android pass through support on iMX8, touch screen and OLED display drivers for the same platform, as well as LTE modem support for Genode.
This reminds me of something I meant to ask about when you posted your Genodians article on adding ARM touchscreen support: What would be involved with bringing touchscreen support to the PC platform?
I don't know if anyone is familiar with the interface(s) for active pens, which would be the icing on the cake, but it would be really nice to be able to test whatever touch UIs are developed for phones/tablets on the laptop as well.
the general support was added already in 2015 (see release notes [0]) for one specific touch device used with one notebook back then.
Since then, however, the topic was not relevant anymore nor integrated with Sculpt. It boils down to write or port the touch device driver for the desired/specific notebook, calibrate/sync the resolution of the touch device to the currently used screen resolution in Sculpt and potentially additional UI work.
[0] https://genode.org/documentation/release-notes/15.02
Cheers,
On 1/5/21 9:17 AM, Alexander Boettcher wrote:
Hello,
On 04.01.21 22:47, John J. Karcher wrote:
[snip]
What would be involved with bringing touchscreen support to the PC platform?
I don't know if anyone is familiar with the interface(s) for active pens, which would be the icing on the cake, but it would be really nice to be able to test whatever touch UIs are developed for phones/tablets on the laptop as well.
the general support was added already in 2015 (see release notes [0]) for one specific touch device used with one notebook back then.
Since then, however, the topic was not relevant anymore nor integrated with Sculpt. It boils down to write or port the touch device driver for the desired/specific notebook, calibrate/sync the resolution of the touch device to the currently used screen resolution in Sculpt and potentially additional UI work.
I'm curious to see if I can advance the ball on this a little bit, as a developer learning experience as well as to actually get the feature.
From what I've read, PC laptop touchscreens and pens generate USB HID events, so it shouldn't be necessary to write low-level drivers for each model.
As a short-term goal, I would like to be a able to see (i.e. log) the touchscreen/pen events within Sculpt. I'd like to use the new USB driver model so it's useful going forward, preferably as a depot package.
Is my understanding correct? Does anyone have any guidance on where to start?
Thanks!
John J. Karcher devuser@alternateapproach.com
On 18.01.21 18:40, John J. Karcher wrote:
What would be involved with bringing touchscreen support to the PC platform?
I don't know if anyone is familiar with the interface(s) for active pens, which would be the icing on the cake, but it would be really nice to be able to test whatever touch UIs are developed for phones/tablets on the laptop as well.
the general support was added already in 2015 (see release notes [0]) for one specific touch device used with one notebook back then.
Since then, however, the topic was not relevant anymore nor integrated with Sculpt. It boils down to write or port the touch device driver for the desired/specific notebook, calibrate/sync the resolution of the touch device to the currently used screen resolution in Sculpt and potentially additional UI work.
I'm curious to see if I can advance the ball on this a little bit, as a developer learning experience as well as to actually get the feature.
From what I've read, PC laptop touchscreens and pens generate USB HID events, so it shouldn't be necessary to write low-level drivers for each model.
[0] was indeed a USB touchscreen back then from Wacom. If you have another vendor for your target device, you will need to come up with another touch driver.
As a short-term goal, I would like to be a able to see (i.e. log) the touchscreen/pen events within Sculpt. I'd like to use the new USB driver model so it's useful going forward, preferably as a depot package.
Is my understanding correct? Does anyone have any guidance on where to start?
In principle yes. First find out which touch device you have for your target hardware. Write or port the touch driver. You may have a look into our usb_hid driver, which has the USB touch Wacom driver already enabled via the dde_linux approach.
Cheers,
-- Alexander Boettcher Genode Labs
https://www.genode-labs.com - https://www.genode.org
Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Hi John,
From what I've read, PC laptop touchscreens and pens generate USB HID events, so it shouldn't be necessary to write low-level drivers for each model.
Many PC platform touchscreens (and also some touchpads) use the I2C HID [1] interface. You may have a look into this protocol since it might enable a variety of devices.
Best regards, Johannes
[1]: https://docs.microsoft.com/en-us/previous-versions/windows/hardware/ design/dn642101(v=vs.85)
Hi Genodians,
I want to share my goals for 2021 too.
I was fascinated to read about Norman's goal to have a Genode-based phone, especially Pinephone. Because last year I spent to launch Genode on Pinephone. My 2020 goal was to have a simple working prototype that could send and receive SMS at least. I have ported some drivers: USB host, USB Modem, GPIO. Even though those drivers are not clean enough, I published my working branch on Github: https://github.com/iloskutov/genode/tree/pinephone. To achieve my goal, I still need to implement Framebuffer, I2C, and Touch Screen drivers. Now I am trying to port Linux framebuffer driver using dde_linux, but I have not succeeded in this yet.
So in 2021, I am going to continue work on Pinephone support in my spare time. I hope the official Genode support of this hardware gives me more motivation to continue this work. I want to implement the Framebuffer first. Then I will add I2C and TouchScreen drivers, and it should be easy. Also, I need to clean up my existing code and rebase it to the current Genode master.
I hope at least something from my work could help Norman's effort and all Genodians community.
-- Best Regards Ivan Loskutov
Hi Ivan,
thank you so much for joining the road-map discussion, and in particular for your enthusiasm about the Genode-on-Pinephone topic!
I was fascinated to read about Norman's goal to have a Genode-based phone, especially Pinephone. Because last year I spent to launch Genode on Pinephone. My 2020 goal was to have a simple working prototype that could send and receive SMS at least. I have ported some drivers: USB host, USB Modem, GPIO. Even though those drivers are not clean enough, I published my working branch on Github: https://github.com/iloskutov/genode/tree/pinephone. To achieve my goal, I still need to implement Framebuffer, I2C, and Touch Screen drivers. Now I am trying to port Linux framebuffer driver using dde_linux, but I have not succeeded in this yet.
This is just fantastic! I'm pretty sure that your existing work will accelerate the project a lot. In particular, while following my plan to jump through the hoops of the driver-porting process myself in order to document the process for future developers, having working drivers as reference is extremely valuable.
I also see the Pinephone project as motivation to revisit the DDE-Linux approach. E.g., currently I'm pondering about possible ways of leveraging Goa to streamline the work flows. If this works out well (I don't know yet), it might be worth bringing all drivers for this particular SoC into this new driver-porting framework, as a reference.
So in 2021, I am going to continue work on Pinephone support in my spare time. I hope the official Genode support of this hardware gives me more motivation to continue this work. I want to implement the Framebuffer first. Then I will add I2C and TouchScreen drivers, and it should be easy. Also, I need to clean up my existing code and rebase it to the current Genode master.
That is music in my ears. :-)
Best regards Norman
Dear Genode community,
I want to thank everyone of you who participated in the road-map discussion. Your enthusiasm and interest in such a variety of topics is delightful! I have now tried to condense all this information into our road map for this year:
https://genode.org/about/road-map
Even though not every single topic made it to the official road map, I hope that you find the plan compelling and in line with our joint discussion.
I sense that we have an exciting year ahead of us.
Cheers Norman
Reading the roadmap from the linked page. With Pine64 do you mean Allwinner A64 soc? Pine64 is the name of the company producing devices with at least two ARM socs and a couple of smaller risciv.
Den fre 15 jan. 2021 14:26Norman Feske norman.feske@genode-labs.com skrev:
Dear Genode community,
I want to thank everyone of you who participated in the road-map discussion. Your enthusiasm and interest in such a variety of topics is delightful! I have now tried to condense all this information into our road map for this year:
https://genode.org/about/road-map
Even though not every single topic made it to the official road map, I hope that you find the plan compelling and in line with our joint discussion.
I sense that we have an exciting year ahead of us.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Michael,
On Fri, Jan 15, 2021 at 16:18:35 CET, Michael Grunditz wrote:
Reading the roadmap from the linked page. With Pine64 do you mean Allwinner A64 soc? Pine64 is the name of the company producing devices with at least two ARM socs and a couple of smaller risciv.
You're right, the term is a bit vague. What the road map should state (and we will change that) is: PINE A64-LTS SBC https://pine64.com/product/pine-a64-lts/.
Greets
The part of the roadmap that interests me the most is the GPU support part. This is something I'm really interested in and I do already have working mesa 20.1 port for Genode along with both kernel and userspace driver parts targetting qemu virtual GPU (virgl). The kernel part was borrowed from Linux 5.8 and ported using "forked" dde_linux code.
The main problem is my port is not compatible with existing Genode windowing system. My initial goal was to support Linux DRM/KMS APIs in Genode. While working on this I decided to omit the KMS part of the duo, but DRM parts are complete enough to run mesa EGL/DRM backend without major modifications. My end goal is to get Qt EGLFS backend working and have GLESv2 accelarated QML GUI running on top of it. The only missing part right now is the EGLFS backend port. I'm not there yet only because I got distracted by my clang port :P.
Even though my plans are probably not fully aligned with Genode Labs, I think the mesa port I have might save you some porting time.
/ptw
On Fri, 2021-01-15 at 14:25 +0100, Norman Feske wrote:
Dear Genode community,
I want to thank everyone of you who participated in the road-map discussion. Your enthusiasm and interest in such a variety of topics is delightful! I have now tried to condense all this information into our road map for this year:
https://genode.org/about/road-map
Even though not every single topic made it to the official road map, I hope that you find the plan compelling and in line with our joint discussion.
I sense that we have an exciting year ahead of us.
Cheers Norman
Hi Piotr,
On 1/16/21 10:03 AM, Piotr Tworek wrote:
The part of the roadmap that interests me the most is the GPU support part. This is something I'm really interested in and I do already have working mesa 20.1 port for Genode along with both kernel and userspace driver parts targetting qemu virtual GPU (virgl). The kernel part was borrowed from Linux 5.8 and ported using "forked" dde_linux code.
The main problem is my port is not compatible with existing Genode windowing system. My initial goal was to support Linux DRM/KMS APIs in Genode. While working on this I decided to omit the KMS part of the duo, but DRM parts are complete enough to run mesa EGL/DRM backend without major modifications. My end goal is to get Qt EGLFS backend working and have GLESv2 accelarated QML GUI running on top of it. The only missing part right now is the EGLFS backend port. I'm not there yet only because I got distracted by my clang port :P.
Even though my plans are probably not fully aligned with Genode Labs, I think the mesa port I have might save you some porting time.
Sounds interesting, we will have to update Mesa anyway this year. Is there a branch I can take a look at? Our goal this year is to resurrect our Mesa/GPU multiplexer line of work in order to have native GPU acceleration back on Genode. I personally have not looked into EGLFS but it might be worth a try.
Regards,
Sebastian
On Mon, 2021-01-18 at 16:11 +0100, Sebastian Sumpf wrote:
Hi Piotr,
On 1/16/21 10:03 AM, Piotr Tworek wrote:
The part of the roadmap that interests me the most is the GPU support part. This is something I'm really interested in and I do already have working mesa 20.1 port for Genode along with both kernel and userspace driver parts targetting qemu virtual GPU (virgl). The kernel part was borrowed from Linux 5.8 and ported using "forked" dde_linux code.
The main problem is my port is not compatible with existing Genode windowing system. My initial goal was to support Linux DRM/KMS APIs in Genode. While working on this I decided to omit the KMS part of the duo, but DRM parts are complete enough to run mesa EGL/DRM backend without major modifications. My end goal is to get Qt EGLFS backend working and have GLESv2 accelarated QML GUI running on top of it. The only missing part right now is the EGLFS backend port. I'm not there yet only because I got distracted by my clang port :P.
Even though my plans are probably not fully aligned with Genode Labs, I think the mesa port I have might save you some porting time.
Sounds interesting, we will have to update Mesa anyway this year. Is there a branch I can take a look at?
Right now all the code sits in a separate private repository. It contains some stuff which I'm not ready to share yet. I can extract the relevant parts into a new repo and push it to github. I'll just need some time to do it. I'll let you know once its done.
Our goal this year is to resurrect our Mesa/GPU multiplexer line of work in order to have native GPU acceleration back on Genode. I personally have not looked into EGLFS but it might be worth a try.
EGLFS is basically a QPA plugin that allows you to run Qt on top of EGL without an actual windowing system. Useful stuff if you work in embedded world.
Regards,
Sebastian
The part of the roadmap that interests me the most is the GPU support part. This is something I'm really interested in and I do already have working mesa 20.1 port for Genode along with both kernel and userspace driver parts targetting qemu virtual GPU (virgl). The kernel part was borrowed from Linux 5.8 and ported using "forked" dde_linux code.
The main problem is my port is not compatible with existing Genode windowing system. My initial goal was to support Linux DRM/KMS APIs in Genode. While working on this I decided to omit the KMS part of the duo, but DRM parts are complete enough to run mesa EGL/DRM backend without major modifications. My end goal is to get Qt EGLFS backend working and have GLESv2 accelarated QML GUI running on top of it. The only missing part right now is the EGLFS backend port. I'm not there yet only because I got distracted by my clang port :P.
Even though my plans are probably not fully aligned with Genode Labs, I think the mesa port I have might save you some porting time.
/ptw
On Fri, 2021-01-15 at 14:25 +0100, Norman Feske wrote:
Dear Genode community,
I want to thank everyone of you who participated in the road-map discussion. Your enthusiasm and interest in such a variety of topics is delightful! I have now tried to condense all this information into our road map for this year:
https://genode.org/about/road-map
Even though not every single topic made it to the official road map, I hope that you find the plan compelling and in line with our joint discussion.
I sense that we have an exciting year ahead of us.
Cheers Norman
-
Alexander Boettcher -
Axel Heider -
Christian Helmuth -
Christian Prochaska -
Colin Parker -
Ivan Loskutov -
Johannes Kliemann -
Johannes Schlatow -
John J. Karcher -
Josef Söntgen -
Martin Stein -
Michael Grunditz -
Norman Feske -
Piotr Tworek -
Sebastian Sumpf -
Sid Hussmann -
Stefan Kalkowski -
Tomasz Gajewski -
ttcoder＠netcourrier.com