Roadmap 2017

[Christian Helmuth]

Hi Peter,

Yes getting Genode to run on your "shiny new Lenovo x260" would be a
good thing!... here, basic leading edge platform support seem
critical if the Genode community is to attract (and keep) more
capable developers. I recently invested in a DELL XPS 15.. as the
x250 suggested at the time only came with 16Gig of ram.. so if there
is a Laptop hardware list that supports Genode development, I will
help make it happen, but it would be great if supporting the DELL
XPS 13, 15 were on the Genode development ToDo: list.

There is an unofficial hardware-compatibility list maintained by Josef
Söntgen at http://usr.sysret.de/jws/genode/hcl.html that gathers what
we, Genode Labs team, tested and also other Genode users reported.
This said, hardware compatibility is already a kind of community
effort and I doubt the Genode team in Dresden will be able to extend
their efforts to enable specific x86 devices considerably more. If you
like to help to enable the XPS 13/15, you are very welcome to post
detailed hardware specifications, report which devices work currently
and which don't as well as provide more information to help others to
support you.

I find encouragement that Genode already supports the Zynq_7000 SOC.
Then it might be good to support at least one of the most common
ARMv8_64 bit targets... most likely the Raspberry Pi 3..

The Raspberry Pi 3 is fairly appealing platform and we also discussed
to add support to Genode during some coffee breaks. For me the topic
has two main questions: 1) What could be the main motivation to
support the RPi 3 (or any other ARMv8 device)? 2) If we add support,
to which extend (regarding peripherals) should we support the platform
and can we avoid regressions in the future.

Both questions have much room for personal opinions, but for me the
main motivation (1) can only be that I myself (or any other active
participant of the Genode community) likes to use the device in a
reasonable application scenario. Then regarding (2), the required
support for peripherals is also defined and the user of the platform
will naturally test the device, which uncovers regressions. Do you
have an application scenario in mind?

Regards

[Sebastian Sumpf]

Hi everyone,

for 2017 my goal is to get Intel graphics hardware support into Genode.
By now I have the intel_fb driver running on Broadwell, featuring OpenGL
and libDRM, all in one component. The future task is to separate the
driver from libDRM and define some sort of GPU session so multiple
clients can make use of the GPU.

Sebastian

Hello everyone,
the end of the year is approaching. So it is the right time to make up
our minds for the upcoming year.
Review of the past year
-----------------------
When reviewing the roadmap for 2016, it is quite clear that our initial
goals moved a bit out of focus throughout the year. Our overall theme
was to make Genode more easily available outside the inner circle of
developers. Topics like system configuration, package management, and
tutorials spring to mind. However, the four releases of 2016 were mostly
concerned with base technologies rather than end-user facing features.
* RISC-V architecture
* Hosting Genode on top of the Muen separation kernel
* Using Genode with the seL4 kernel
* Fundamental revision of the framework API
* Huge device-driver improvements (like wifi, graphics, USB, ACPI)
* Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies
(like RISC-V, seL4, Muen) is very exciting from a developer's
perspective and creates new opportunities for collaboration. On that
account, I am particularly happy about the relationships that we now
enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users
should be prioritized over extending the user base. The existing users
are primarily interested in API stability and maturity. So personally, I
made it my priority to free Genode from legacies and known architectural
limitations. Over the year, we introduced and cultivated the new
framework API that is designed for safety, achieved cross-kernel binary
compatibility, and revised the framework's most fundamental protocols.
This was quite a feat! Now, knowing that the time of sweeping
architectural changes lies behind us, I feel much more confident that
users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very
satisfied with the outcome of the past year. After all, the roadmap is a
plan. Plans can be changed.
My goals for 2017
-----------------
There are still two low-level construction sites left that I want to
wrap up, which is the introduction of application binary interfaces
(ABI) and ability to dynamically configure the init component. The ABIs
largely decouple library implementations from their users and thereby
will greatly ease the creation of a scalable package-management system
on top of Genode. The dynamic init will potentially cover the use cases
of most of today's custom-implemented Genode runtime environments (like
launchpad, cli_monitor) by one versatile solution that scales well.
This, in turn, will facilitate the creation of more sophisticated and
dynamic Genode systems. In contrast to the "Turmvilla" scenario that I
am currently using, such systems could be defined and reshaped not only
at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on
stressing the framework, both in terms of using it much more intensively
and by creating artificial stress. By the time of the release of version
17.05, Genode should - in principle - be well suited for the the
maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two
principle limitations. First, the system is hard to set up. Installing
it on a new machine is quite a burden. (i.e., I have shiny new x260 on
my desk that gathers dust because I don't find the time to install
Genode on it) This needs to be fixed! Second, the system does not stay
up to date automatically. I would love to always use the components of
the latest master branch so that I can detect and correct regressions
that slip through our automated tests. Consequently, I need to craft a
solution that allows me to update Genode on the fly and - if anything
goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics
outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official
roadmap by mid of January.
Cheers
Norman

[Norman Feske]

Hi Ben,

I would like to see Genode being compiled on Genode. I know that a run
script exists for that, but it doesn't really work, especially given
Genode's (build) dependence on tools that haven't been ported yet (e.g.
expect, tclsh, autotools). Once all of Genode, including the ports of
3rd-party software, will build properly on Genode, testing and debugging
will be faster and easier.

this topic fits nicely into my ambition to stress Genode. I agree that
hosting the entire build infrastructure and implementing the development
workflow directly on Genode sounds intriguing.

The key to achieve that is to get noux up to speed, and to revisit some
of its inner workings. I have some ideas in this respect that I'd like
to try out. But before it is worthwhile to start with that, we should
address a few limitations of its underpinnings, in particular the VFS.

Another day-to-day scenario that is much easier to realize - compared to
the full development worklow - would be a multi-component email
application where multiple noux instances are used for dedicated tasks
like fetching email, browsing local folders, composing an email, or
sending email. Each noux instance could be tailored to its purpose.
E.g., the one for browsing the local folders wouldn't have network
access. So emails stored locally cannot leak to the network. This
scenario is less demanding than the development scenario and would
possibly reach more users. So we might better first go for this one?

Cheers
Norman

[Jookia]

Post by Norman Feske
The key to achieve that is to get noux up to speed, and to revisit some
of its inner workings. I have some ideas in this respect that I'd like
to try out. But before it is worthwhile to start with that, we should
address a few limitations of its underpinnings, in particular the VFS.
Another day-to-day scenario that is much easier to realize - compared to
the full development worklow - would be a multi-component email
application where multiple noux instances are used for dedicated tasks
like fetching email, browsing local folders, composing an email, or
sending email. Each noux instance could be tailored to its purpose.
E.g., the one for browsing the local folders wouldn't have network
access. So emails stored locally cannot leak to the network. This
scenario is less demanding than the development scenario and would
possibly reach more users. So we might better first go for this one?
Cheers
Norman

Interesting you'd mention this!

I have developed a GNU Bash-based application that does something like this on
my system in conjunction with mutt, mbsync and msmtp. There's no reason it
couldn't be ported to run in different Noux instances, or other
clients/fetchers/senders as long as they're okay with handling Maildir systems.

It'd be interesting to get some use out of it since it's reached the peak point
of '90% done' with most of the current system finished (including
documentation), but without a non-programmer tutorial or support for more use
cases than just mine. If you're interested I'll throw some code up on GitLab or
GitHub with it.

Jookia.

[Johannes Schlatow]

Thanks, Norman, for sharing and starting the 'discussion'. Here are a few comments from my perspective:

1) I like the idea of the multi-component email application. Let me be a bit more visionary and extend this to a post-2017 scope:
I am running my own mailserver (Kolab) for quite some years now. The reason once was (and still is) to protect my privacy. Sure, end-to-end encryption would also be a solution but has quite some drawbacks on the usability side. It appeals to me that running a multi-component mailserver on a Genode system could improve the security of those systems quite a bit. I believe Genode's component-based architecture already reflects the way emails are processed on current 'legacy' systems but provides better isolation and separation. Of course this would be a huge undertaking but I'd like to keep this in the back of my mind for the future beyond 2017.

2) @Christian: Thumbs up for the tiling window manager ;-)

3) About my goals:
a) There will (hopefully) be some improvements for the Zynq-7000 (HDMI support, NIC performance issues).
b) In addition, as you might know, we are investigating model-based methods for auto-configuration in a far wider scope that the typical Genode applications. However, I'd like to extract the essential mechanisms to make this usable for general-purpose Genode systems. The benefit of this would be that new users don't need to care about how to setup the config, e.g., for the Turmvilla scenario. This would also address an issue that pops up with the ABI, namely (in)compatibility between different versions of component binaries.
c) I also plan to make extensive use of the tracing framework.

Cheers and happy holidays!
Johannes

[Norman Feske]

Hi Johannes,

Post by Johannes Schlatow
a) There will (hopefully) be some improvements for the Zynq-7000 (HDMI support, NIC performance issues).

Nice! I have already seen a glimpse of it in your world repository. ;-)

Post by Johannes Schlatow
b) In addition, as you might know, we are investigating model-based
methods for auto-configuration in a far wider scope that the typical
Genode applications. However, I'd like to extract the essential
mechanisms to make this usable for general-purpose Genode systems.
The benefit of this would be that new users don't need to care about
how to setup the config, e.g., for the Turmvilla scenario. This would
also address an issue that pops up with the ABI, namely
(in)compatibility between different versions of component binaries.

I really look forward to see how my current line of work regarding
packaging/ABI/deployment aligns with your ideas.

Post by Johannes Schlatow
c) I also plan to make extensive use of the tracing framework.

That's interesting to hear. In my opinion, the tracing framework is a
really distinctive and under-appreciated feature of Genode. Literally
each time we used it, it provided invaluable insights into the behavior
of the system at almost no performance overhead. It's a pity that it is
so rarely used. I'm afraid that this won't change unless we greatly
improve the tooling around it. Right now, one has to manually craft a
trace monitor for each scenario under test. In many cases, this is too
much of a burden to start using it. It would be great if your work can
contribute to make the tracing more accessible for everyone.

Cheers
Norman

[Emery Hemingway]

Hello list,

My plans for the next year:

Libc
----

This next release will hopefully feature a more asynchronous VFS
library which can move a number of improvements at libc forward.
When the internals of libc settle and stabilize, I hope to make
performance improvements to libc for the sake of my next topic...


Package management
------------------

I had big hopes when I worked to port the Nix package manager to
Genode, but in reality sourced-based package management was not
economical when compared to native POSIX counterparts. However,
a fixed ABI across kernels is a game-changer. I would like to
combine this with asynchronous session requests and again
experiment with alternative package management flows.


Nim
---

This year I successfully compiled and executed Nim language code
for Genode, but next year I would like to take time to make proper
C++ glue between the Nim standard library and Genode. My motivation
is to port or build network applications written in a modern
langauge rather than rely on the BSD sockets API.


Gaming
------

For me, gaming was the gateway drug to general purpose computing.
I would like to see Genode able to play the same role for the next
generation as DOS played for me. As a low priority task I hope to
work towards making a gaming console like system using the "lego"
composition technique. So a modular menuing system and maybe
integrating some package management. Now that I have the Libretro
API/ABI nearly supported, getting more games to run has been more
or less trivial.


Best wishes for 2017,
Emery

[Emery Hemingway]

Hello,

My personal roadmap was written on a sleepless night before 33C3,
not a great idea as I expected that I would probably would have
alterations after congress, so here is an ammendment.

I still haven't made it through my list of talks to watch at home
but the talk of most immediate interest to me was 'Bootstraping a
slightly more secure laptop' - https://trmm.net/Heads_33c3

The TL;DR is that if coreboot can execute Linux from flash and
bypass the BIOS, MBR, and UEFI, then the TCB of the boot process
shrinks. The boot process can also be measured with and verified
with a TPM.

My though of course was that the same could be done with Genode,
so another project I would like to work on this year is to
replace some of the legacy bootstrapping stages on my laptop.
This will be a piecemeal path, replacing GRUB, interoptibilty
with coreboot, and maybe some TPM support. I plan to work
cautiously and no more than one step ahead of what I can
actually boot with.


Cheers,
Emery

[Norman Feske]

Hello,

Post by Emery Hemingway
The TL;DR is that if coreboot can execute Linux from flash and
bypass the BIOS, MBR, and UEFI, then the TCB of the boot process
shrinks. The boot process can also be measured with and verified
with a TPM.

this is certainly an interesting direction to explore! I agree that we
have to eventually overcome our current dependency from the legacy
multi-boot method. Your ambition is one extreme end of the spectrum.
Another topic would be the support for UEFI boot.

As a further addition to our road map with respect to my goal for a
long-term supportable version 17.05, I would like to add a tool-chain
update. It is sensible to update it before this point so the longer-term
maintenance will be based on the same tool chain as used by the ongoing
development for about 18-24 months (which is our typical interval for
tool-chain updates).
* Support for C++14, C++17
* Better support for reproducible builds
* The uniform definition of 'size_t' as 'unsigned long' to
harmonize the ABIs of C++ libraries like Qt5 across 32/64-bit
architectures (this will be specific to Genode's tool chain)
* Tighter integration of the tool chain with Genode's ports
mechanism and build system. (right now, we use a separate
tool-chain creation script, which does not ensure that the
used tool chain matches the Genode version)

Cheers
Norman

[Frank]

Thanks for sharing,

About the package management on the road map: It would be nice if Genode
was the first system that really protects you from hostile programs. And
not in the Apple way (trust us).

End point security is really important these days. I think it's
important you can install packages you don't trust that much while
maintaining as much security as possible.

Greetings,
Frank

Hello everyone,
the end of the year is approaching. So it is the right time to make up
our minds for the upcoming year.
Review of the past year
-----------------------
When reviewing the roadmap for 2016, it is quite clear that our initial
goals moved a bit out of focus throughout the year. Our overall theme
was to make Genode more easily available outside the inner circle of
developers. Topics like system configuration, package management, and
tutorials spring to mind. However, the four releases of 2016 were mostly
concerned with base technologies rather than end-user facing features.
* RISC-V architecture
* Hosting Genode on top of the Muen separation kernel
* Using Genode with the seL4 kernel
* Fundamental revision of the framework API
* Huge device-driver improvements (like wifi, graphics, USB, ACPI)
* Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies
(like RISC-V, seL4, Muen) is very exciting from a developer's
perspective and creates new opportunities for collaboration. On that
account, I am particularly happy about the relationships that we now
enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users
should be prioritized over extending the user base. The existing users
are primarily interested in API stability and maturity. So personally, I
made it my priority to free Genode from legacies and known architectural
limitations. Over the year, we introduced and cultivated the new
framework API that is designed for safety, achieved cross-kernel binary
compatibility, and revised the framework's most fundamental protocols.
This was quite a feat! Now, knowing that the time of sweeping
architectural changes lies behind us, I feel much more confident that
users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very
satisfied with the outcome of the past year. After all, the roadmap is a
plan. Plans can be changed.
My goals for 2017
-----------------
There are still two low-level construction sites left that I want to
wrap up, which is the introduction of application binary interfaces
(ABI) and ability to dynamically configure the init component. The ABIs
largely decouple library implementations from their users and thereby
will greatly ease the creation of a scalable package-management system
on top of Genode. The dynamic init will potentially cover the use cases
of most of today's custom-implemented Genode runtime environments (like
launchpad, cli_monitor) by one versatile solution that scales well.
This, in turn, will facilitate the creation of more sophisticated and
dynamic Genode systems. In contrast to the "Turmvilla" scenario that I
am currently using, such systems could be defined and reshaped not only
at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on
stressing the framework, both in terms of using it much more intensively
and by creating artificial stress. By the time of the release of version
17.05, Genode should - in principle - be well suited for the the
maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two
principle limitations. First, the system is hard to set up. Installing
it on a new machine is quite a burden. (i.e., I have shiny new x260 on
my desk that gathers dust because I don't find the time to install
Genode on it) This needs to be fixed! Second, the system does not stay
up to date automatically. I would love to always use the components of
the latest master branch so that I can detect and correct regressions
that slip through our automated tests. Consequently, I need to craft a
solution that allows me to update Genode on the fly and - if anything
goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics
outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official
roadmap by mid of January.
Cheers
Norman

[Peter Lindener]

Reiterating on Frank's reflection as for the need for truly secure
package management systems (A real reason to use the Genode OS)..

a voter's keyword rule based issue by issue proxy delegation agent(s)
(liquid democracy) will often be implemented by other's, on occasion less
trusted...
with news swirling in the press about election hacking... providing a
truly secure OS that can host a collection of less than fully trusted
agent's who's activity's can be fully monitored... seems like a real win as
a foundation upon which tomorrow's more properly functioning democracy's
might be built..

Genode running on 2nd gen LowRisc seems like the ticket here... lets
bring it ON!

-Peter

Post by Frank
Thanks for sharing,
About the package management on the road map: It would be nice if Genode
was the first system that really protects you from hostile programs. And
not in the Apple way (trust us).
End point security is really important these days. I think it's
important you can install packages you don't trust that much while
maintaining as much security as possible.
Greetings,
Frank

Hello everyone,
the end of the year is approaching. So it is the right time to make up
our minds for the upcoming year.
Review of the past year
-----------------------
When reviewing the roadmap for 2016, it is quite clear that our initial
goals moved a bit out of focus throughout the year. Our overall theme
was to make Genode more easily available outside the inner circle of
developers. Topics like system configuration, package management, and
tutorials spring to mind. However, the four releases of 2016 were mostly
concerned with base technologies rather than end-user facing features.
* RISC-V architecture
* Hosting Genode on top of the Muen separation kernel
* Using Genode with the seL4 kernel
* Fundamental revision of the framework API
* Huge device-driver improvements (like wifi, graphics, USB, ACPI)
* Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies
(like RISC-V, seL4, Muen) is very exciting from a developer's
perspective and creates new opportunities for collaboration. On that
account, I am particularly happy about the relationships that we now
enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users
should be prioritized over extending the user base. The existing users
are primarily interested in API stability and maturity. So personally, I
made it my priority to free Genode from legacies and known architectural
limitations. Over the year, we introduced and cultivated the new
framework API that is designed for safety, achieved cross-kernel binary
compatibility, and revised the framework's most fundamental protocols.
This was quite a feat! Now, knowing that the time of sweeping
architectural changes lies behind us, I feel much more confident that
users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very
satisfied with the outcome of the past year. After all, the roadmap is a
plan. Plans can be changed.
My goals for 2017
-----------------
There are still two low-level construction sites left that I want to
wrap up, which is the introduction of application binary interfaces
(ABI) and ability to dynamically configure the init component. The ABIs
largely decouple library implementations from their users and thereby
will greatly ease the creation of a scalable package-management system
on top of Genode. The dynamic init will potentially cover the use cases
of most of today's custom-implemented Genode runtime environments (like
launchpad, cli_monitor) by one versatile solution that scales well.
This, in turn, will facilitate the creation of more sophisticated and
dynamic Genode systems. In contrast to the "Turmvilla" scenario that I
am currently using, such systems could be defined and reshaped not only
at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on
stressing the framework, both in terms of using it much more intensively
and by creating artificial stress. By the time of the release of version
17.05, Genode should - in principle - be well suited for the the
maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two
principle limitations. First, the system is hard to set up. Installing
it on a new machine is quite a burden. (i.e., I have shiny new x260 on
my desk that gathers dust because I don't find the time to install
Genode on it) This needs to be fixed! Second, the system does not stay
up to date automatically. I would love to always use the components of
the latest master branch so that I can detect and correct regressions
that slip through our automated tests. Consequently, I need to craft a
solution that allows me to update Genode on the fly and - if anything
goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics
outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official
roadmap by mid of January.
Cheers
Norman

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Frank]

Electronic voting is a step further: you have to trust computers you
don't control yourself.

But it would be nice if hackers can't use a game to install a keylogger,
and intercept all your encrypted communication. People want to play
downloaded games on the same computer they use to do banking. Tor, PGP,
and https, are useless when your computer is owned by some hacker
(government or criminal)

Greetings,
Frank

Post by Peter Lindener
Reiterating on Frank's reflection as for the need for truly secure
package management systems (A real reason to use the Genode OS)..
a voter's keyword rule based issue by issue proxy delegation
agent(s) (liquid democracy) will often be implemented by other's, on
occasion less trusted...
with news swirling in the press about election hacking... providing
a truly secure OS that can host a collection of less than fully
trusted agent's who's activity's can be fully monitored... seems like
a real win as a foundation upon which tomorrow's more properly
functioning democracy's might be built..
Genode running on 2nd gen LowRisc seems like the ticket here...
lets bring it ON!
-Peter
Thanks for sharing,
About the package management on the road map: It would be nice if Genode
was the first system that really protects you from hostile
programs. And
not in the Apple way (trust us).
End point security is really important these days. I think it's
important you can install packages you don't trust that much while
maintaining as much security as possible.
Greetings,
Frank

Hello everyone,
the end of the year is approaching. So it is the right time to

make up

our minds for the upcoming year.
Review of the past year
-----------------------
When reviewing the roadmap for 2016, it is quite clear that our

initial

goals moved a bit out of focus throughout the year. Our overall

theme

was to make Genode more easily available outside the inner circle of
developers. Topics like system configuration, package

management, and

tutorials spring to mind. However, the four releases of 2016

were mostly

concerned with base technologies rather than end-user facing

features.

* RISC-V architecture
* Hosting Genode on top of the Muen separation kernel
* Using Genode with the seL4 kernel
* Fundamental revision of the framework API
* Huge device-driver improvements (like wifi, graphics, USB, ACPI)
* Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies
(like RISC-V, seL4, Muen) is very exciting from a developer's
perspective and creates new opportunities for collaboration. On that
account, I am particularly happy about the relationships that we now
enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users
should be prioritized over extending the user base. The existing

users

are primarily interested in API stability and maturity. So

personally, I

made it my priority to free Genode from legacies and known

architectural

limitations. Over the year, we introduced and cultivated the new
framework API that is designed for safety, achieved cross-kernel

binary

compatibility, and revised the framework's most fundamental

protocols.

This was quite a feat! Now, knowing that the time of sweeping
architectural changes lies behind us, I feel much more confident

that

users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very
satisfied with the outcome of the past year. After all, the

roadmap is a

plan. Plans can be changed.
My goals for 2017
-----------------
There are still two low-level construction sites left that I want to
wrap up, which is the introduction of application binary interfaces
(ABI) and ability to dynamically configure the init component.

The ABIs

largely decouple library implementations from their users and

thereby

will greatly ease the creation of a scalable package-management

system

on top of Genode. The dynamic init will potentially cover the

use cases

of most of today's custom-implemented Genode runtime

environments (like

launchpad, cli_monitor) by one versatile solution that scales well.
This, in turn, will facilitate the creation of more

sophisticated and

dynamic Genode systems. In contrast to the "Turmvilla" scenario

that I

am currently using, such systems could be defined and reshaped

not only

at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on
stressing the framework, both in terms of using it much more

intensively

and by creating artificial stress. By the time of the release of

version

17.05, Genode should - in principle - be well suited for the the
maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I

see two

principle limitations. First, the system is hard to set up.

Installing

it on a new machine is quite a burden. (i.e., I have shiny new

x260 on

my desk that gathers dust because I don't find the time to install
Genode on it) This needs to be fixed! Second, the system does

not stay

up to date automatically. I would love to always use the

components of

the latest master branch so that I can detect and correct

regressions

that slip through our automated tests. Consequently, I need to

craft a

solution that allows me to update Genode on the fly and - if

anything

goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics
outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the

official

roadmap by mid of January.
Cheers
Norman

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
<https://lists.sourceforge.net/lists/listinfo/genode-main>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Peter Lindener]

Franks observation : "*you have to trust computers you don't control
yourself*."
is true up to the point where many computer's run by independent
organizations are configured to automatically cross audit each other.. As
I see it Genode could help with secure hosting of this kind of error
monitored distributed computation service (Grove-Clarke Mechanism based
strategic approval voting game equilibrium solver)...

then, none of this seems viable without the kind of more rigorous
security that Genode's hierarchical structure promises to provide.. the
rise of Genode can not come soon enough to address the current disarray in
cyber space.

-Peter

Post by Frank
Electronic voting is a step further: you have to trust computers you
don't control yourself.
But it would be nice if hackers can't use a game to install a keylogger,
and intercept all your encrypted communication. People want to play
downloaded games on the same computer they use to do banking. Tor, PGP,
and https, are useless when your computer is owned by some hacker
(government or criminal)
Greetings,
Frank

Post by Peter Lindener
Reiterating on Frank's reflection as for the need for truly secure
package management systems (A real reason to use the Genode OS)..
a voter's keyword rule based issue by issue proxy delegation
agent(s) (liquid democracy) will often be implemented by other's, on
occasion less trusted...
with news swirling in the press about election hacking... providing
a truly secure OS that can host a collection of less than fully
trusted agent's who's activity's can be fully monitored... seems like
a real win as a foundation upon which tomorrow's more properly
functioning democracy's might be built..
Genode running on 2nd gen LowRisc seems like the ticket here...
lets bring it ON!
-Peter
Thanks for sharing,
About the package management on the road map: It would be nice if Genode
was the first system that really protects you from hostile programs. And
not in the Apple way (trust us).
End point security is really important these days. I think it's
important you can install packages you don't trust that much while
maintaining as much security as possible.
Greetings,
Frank

Hello everyone,
the end of the year is approaching. So it is the right time to

make up

our minds for the upcoming year.
Review of the past year
-----------------------
When reviewing the roadmap for 2016, it is quite clear that our

initial

goals moved a bit out of focus throughout the year. Our overall

theme

was to make Genode more easily available outside the inner circle

of

Post by Peter Lindener

developers. Topics like system configuration, package

management, and

tutorials spring to mind. However, the four releases of 2016

were mostly

concerned with base technologies rather than end-user facing

features.

* RISC-V architecture
* Hosting Genode on top of the Muen separation kernel
* Using Genode with the seL4 kernel
* Fundamental revision of the framework API
* Huge device-driver improvements (like wifi, graphics, USB, ACPI)
* Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies
(like RISC-V, seL4, Muen) is very exciting from a developer's
perspective and creates new opportunities for collaboration. On

that

Post by Peter Lindener

account, I am particularly happy about the relationships that we

now

Post by Peter Lindener

enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users
should be prioritized over extending the user base. The existing

users

are primarily interested in API stability and maturity. So

personally, I

made it my priority to free Genode from legacies and known

architectural

limitations. Over the year, we introduced and cultivated the new
framework API that is designed for safety, achieved cross-kernel

binary

compatibility, and revised the framework's most fundamental

protocols.

This was quite a feat! Now, knowing that the time of sweeping
architectural changes lies behind us, I feel much more confident

that

users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very
satisfied with the outcome of the past year. After all, the

roadmap is a

plan. Plans can be changed.
My goals for 2017
-----------------
There are still two low-level construction sites left that I want

to

Post by Peter Lindener

wrap up, which is the introduction of application binary interfaces
(ABI) and ability to dynamically configure the init component.

The ABIs

largely decouple library implementations from their users and

thereby

will greatly ease the creation of a scalable package-management

system

on top of Genode. The dynamic init will potentially cover the

use cases

of most of today's custom-implemented Genode runtime

environments (like

launchpad, cli_monitor) by one versatile solution that scales well.
This, in turn, will facilitate the creation of more

sophisticated and

dynamic Genode systems. In contrast to the "Turmvilla" scenario

that I

am currently using, such systems could be defined and reshaped

not only

at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on
stressing the framework, both in terms of using it much more

intensively

and by creating artificial stress. By the time of the release of

version

17.05, Genode should - in principle - be well suited for the the
maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I

see two

principle limitations. First, the system is hard to set up.

Installing

it on a new machine is quite a burden. (i.e., I have shiny new

x260 on

my desk that gathers dust because I don't find the time to install
Genode on it) This needs to be fixed! Second, the system does

not stay

up to date automatically. I would love to always use the

components of

the latest master branch so that I can detect and correct

regressions

that slip through our automated tests. Consequently, I need to

craft a

solution that allows me to update Genode on the fly and - if

anything

goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics
outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the

official

roadmap by mid of January.
Cheers
Norman

------------------------------------------------------------

------------------

Post by Peter Lindener
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
<https://lists.sourceforge.net/lists/listinfo/genode-main>
------------------------------------------------------------

------------------

Post by Peter Lindener
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Madhu Macaque Labs]

I am actually designing a voting machine right now !
We are looking at Genode but the Indian voting machine in its
current incarnation is fairly simple, so a full OS seems an overkill.
A small rtos that can be formally verified seems more appropriate.

HW platform is tentatively i.MX7 or I.MX8, so trustzone with high
assurance boot and tamper is available. i.MX8 variants also provide
hw isolation and dram encryption. So a pretty good HW base for a secure
platform.

Post by Peter Lindener
Reiterating on Frank's reflection as for the need for truly secure
package management systems (A real reason to use the Genode OS)..
a voter's keyword rule based issue by issue proxy delegation agent(s)
(liquid democracy) will often be implemented by other's, on occasion less
trusted...
with news swirling in the press about election hacking... providing a
truly secure OS that can host a collection of less than fully trusted
agent's who's activity's can be fully monitored... seems like a real win as
a foundation upon which tomorrow's more properly functioning democracy's
might be built..
Genode running on 2nd gen LowRisc seems like the ticket here... lets
bring it ON!
-Peter

Post by Frank
Thanks for sharing,
About the package management on the road map: It would be nice if Genode
was the first system that really protects you from hostile programs. And
not in the Apple way (trust us).
End point security is really important these days. I think it's
important you can install packages you don't trust that much while
maintaining as much security as possible.
Greetings,
Frank

Hello everyone,
the end of the year is approaching. So it is the right time to make up
our minds for the upcoming year.
Review of the past year
-----------------------
When reviewing the roadmap for 2016, it is quite clear that our initial
goals moved a bit out of focus throughout the year. Our overall theme
was to make Genode more easily available outside the inner circle of
developers. Topics like system configuration, package management, and
tutorials spring to mind. However, the four releases of 2016 were mostly
concerned with base technologies rather than end-user facing features.
* RISC-V architecture
* Hosting Genode on top of the Muen separation kernel
* Using Genode with the seL4 kernel
* Fundamental revision of the framework API
* Huge device-driver improvements (like wifi, graphics, USB, ACPI)
* Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies
(like RISC-V, seL4, Muen) is very exciting from a developer's
perspective and creates new opportunities for collaboration. On that
account, I am particularly happy about the relationships that we now
enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users
should be prioritized over extending the user base. The existing users
are primarily interested in API stability and maturity. So personally, I
made it my priority to free Genode from legacies and known architectural
limitations. Over the year, we introduced and cultivated the new
framework API that is designed for safety, achieved cross-kernel binary
compatibility, and revised the framework's most fundamental protocols.
This was quite a feat! Now, knowing that the time of sweeping
architectural changes lies behind us, I feel much more confident that
users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very
satisfied with the outcome of the past year. After all, the roadmap is a
plan. Plans can be changed.
My goals for 2017
-----------------
There are still two low-level construction sites left that I want to
wrap up, which is the introduction of application binary interfaces
(ABI) and ability to dynamically configure the init component. The ABIs
largely decouple library implementations from their users and thereby
will greatly ease the creation of a scalable package-management system
on top of Genode. The dynamic init will potentially cover the use cases
of most of today's custom-implemented Genode runtime environments (like
launchpad, cli_monitor) by one versatile solution that scales well.
This, in turn, will facilitate the creation of more sophisticated and
dynamic Genode systems. In contrast to the "Turmvilla" scenario that I
am currently using, such systems could be defined and reshaped not only
at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on
stressing the framework, both in terms of using it much more intensively
and by creating artificial stress. By the time of the release of version
17.05, Genode should - in principle - be well suited for the the
maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two
principle limitations. First, the system is hard to set up. Installing
it on a new machine is quite a burden. (i.e., I have shiny new x260 on
my desk that gathers dust because I don't find the time to install
Genode on it) This needs to be fixed! Second, the system does not stay
up to date automatically. I would love to always use the components of
the latest master branch so that I can detect and correct regressions
that slip through our automated tests. Consequently, I need to craft a
solution that allows me to update Genode on the fly and - if anything
goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics
outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official
roadmap by mid of January.
Cheers
Norman

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Josef Söntgen]

Hello everyone,

looking back at the the roadmap of 2016 it is clear that we missed some
items; nevertheless, I think all in all the year went well. Norman already
noted some observations, namely prioritizing the existing user base
over the future one. Looking back at this week's clean-up efforts I
believe that spending more time on refining the base APIs was indeed the
right decision. Using the new interface or switching the used kernel
seamlessly while testing components feels so natural now and with the
ABI mechanism provides a great foundation for building the infrastructure
for package/deployment management.

That being said, one thing I missed from last year's roadmap discussion
(although I am not sure if that was actually discussed on the ML or only
at a coffee break) is the intention of making more information about
Genode available to and by the community, i.e. in the form of writing
how-tos for specific tasks or just by writing informally about interesting
things that happend while working on Genode. Since parts of the APIs were
or are still in flux I understand that it is difficult to write detailed
articles that are valid for the years to come and probably one of the
reason why one hesitates to spend time on that. That merely leaves the
more informal part. Judging by the huge amount of out-dated information
for <insert your favourite topic here> in all the weblogs on the internet
I am not sure if spending time on that is a good idea either. Than again,
were is the harm in documenting the process of writing a new component or
porting existing software [1] to Genode? After all it should be fine if
the focus is more on the process or the methodology. So, that is a goal of
mine for 2017 — scheduled (emphasis on that) writing about what I do with
Genode in hope that it is useful to somebody or even that others join in
:-)

[1] FWIW http://usr.sysret.de/jws/genode/porting_wishlist.html

Apart from that, I am afraid I have no precise items for this year's
roadmap. I agree with Norman; we need the infrastructure to keep a
running Genode system in sync to the latest changes to provide better
test coverage. I imagine that this will keep us busy for some time and
there are still some items from the old roadmap left that needs to be
addressed as well.


Regards
Josef

[Peter Lindener]

Fellow genodians-

Now that Genode's base API is going totally async..

it would be great to see an example of some cooperating processes where
each might have the flexibility to across the network of different
machines...
I realize there are plenty systems for supporting an RPC...
but I gather Genode's new Async perspective, might also better inform how
one might best configure and synchronize / clean_up a set of processes
exchanging data and running possibly on different machines..

That is: an example of how one might best do RPC like things within the
philosophy of the new Genode API would be very helpful... it could start
as more of a toy program, but the thought here is that we might polish and
maintain it as part of Genode's getting started / coding style
documentation...

Is there an existing Genode RPC like example that might be a good
starting point ?

-Peter


On Sat, Jan 7, 2017 at 6:33 AM, Josef Söntgen <

Hello everyone,
looking back at the the roadmap of 2016 it is clear that we missed some
items; nevertheless, I think all in all the year went well. Norman already
noted some observations, namely prioritizing the existing user base
over the future one. Looking back at this week's clean-up efforts I
believe that spending more time on refining the base APIs was indeed the
right decision. Using the new interface or switching the used kernel
seamlessly while testing components feels so natural now and with the
ABI mechanism provides a great foundation for building the infrastructure
for package/deployment management.
That being said, one thing I missed from last year's roadmap discussion
(although I am not sure if that was actually discussed on the ML or only
at a coffee break) is the intention of making more information about
Genode available to and by the community, i.e. in the form of writing
how-tos for specific tasks or just by writing informally about interesting
things that happend while working on Genode. Since parts of the APIs were
or are still in flux I understand that it is difficult to write detailed
articles that are valid for the years to come and probably one of the
reason why one hesitates to spend time on that. That merely leaves the
more informal part. Judging by the huge amount of out-dated information
for <insert your favourite topic here> in all the weblogs on the internet
I am not sure if spending time on that is a good idea either. Than again,
were is the harm in documenting the process of writing a new component or
porting existing software [1] to Genode? After all it should be fine if
the focus is more on the process or the methodology. So, that is a goal of
mine for 2017 — scheduled (emphasis on that) writing about what I do with
Genode in hope that it is useful to somebody or even that others join in
:-)
[1] FWIW http://usr.sysret.de/jws/genode/porting_wishlist.html
Apart from that, I am afraid I have no precise items for this year's
roadmap. I agree with Norman; we need the infrastructure to keep a
running Genode system in sync to the latest changes to provide better
test coverage. I imagine that this will keep us busy for some time and
there are still some items from the old roadmap left that needs to be
addressed as well.
Regards
Josef
--
Josef Söntgen
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Martin Stein]

Hello,

My plans for this year:

* Enhance the Timeout framework to use the performance counters for time
interpolation and RTCs for timestamps

* A server for DHCP and dynamic NIC router configurations to enable
dynamic network configuration

* More automated testing of block drivers and graphical applications
(screenshots, screencasts, pixel hashsums, scripted input)

* Continue my work on remote input and framebuffer

Cheers,
Martin

[Norman Feske]

Hi Josef,

Post by Josef Söntgen
looking back at the the roadmap of 2016 it is clear that we missed some
items; nevertheless, I think all in all the year went well. Norman already
noted some observations, namely prioritizing the existing user base
over the future one. Looking back at this week's clean-up efforts I
believe that spending more time on refining the base APIs was indeed the
right decision. Using the new interface or switching the used kernel
seamlessly while testing components feels so natural now and with the
ABI mechanism provides a great foundation for building the infrastructure
for package/deployment management.

it's really nice to read your reflection, now that we adapted a
significant amount of components to the new API. This is exactly what I
hoped to achieve with the new API!

Post by Josef Söntgen
That being said, one thing I missed from last year's roadmap discussion
(although I am not sure if that was actually discussed on the ML or only
at a coffee break) is the intention of making more information about
Genode available to and by the community, i.e. in the form of writing
how-tos for specific tasks or just by writing informally about interesting
things that happend while working on Genode. Since parts of the APIs were
or are still in flux I understand that it is difficult to write detailed
articles that are valid for the years to come and probably one of the
reason why one hesitates to spend time on that. That merely leaves the
more informal part. Judging by the huge amount of out-dated information
for <insert your favourite topic here> in all the weblogs on the internet
I am not sure if spending time on that is a good idea either. Than again,
were is the harm in documenting the process of writing a new component or
porting existing software [1] to Genode? After all it should be fine if
the focus is more on the process or the methodology. So, that is a goal of
mine for 2017 — scheduled (emphasis on that) writing about what I do with
Genode in hope that it is useful to somebody or even that others join in
:-)

I like the idea very much. Dropping a comprehensive release-notes
document every three months is not perfect to keep the attention of
interested bystanders captured. A blog-like format would be a very good
addition!

Cheers
Norman

[Martin Stein]

... I forgot:

* Bring the Trustzone VMM demo with a Linux guest to i.MX6

Martin

[Dr. Florian Manfred Grätz]

Dear community,

I am very excited about the entire Genode project and looking forward to
the upcoming releases. Please keep up the quaterly release cycle. Let me
share my thoughts on several issues, which have already been communicated:

* From a newbee's point of view I would say, that you guys are heading
into the right direction: I understand the core component to be a
kernel abstraction layer. Therfore ABI stability of the core would
be awsome - no matter what the kernel is, you could use the same
binaries (as long as you are running on the same processor, of
course) for drivers and applications. That would be a prerequiste
for a working packaging system.
* The build process indeed needs a little make-over. I have noticed
side effects with the ports, which are hard to describe in detail,
as I have not yet fully understood them. Generally speaking the
ports (including the drivers) should be built separately from the
kernel/core/init. Once again - a stable ABI would help. No matter
what the kernel is, you would use the same binaries for the
drivers/applications.
* A dynamic init component would greatly help, too: reconfigure your
system, don't rebuild it. This would also enhance the turmvilla
scenario.

Let me also add an idea of mine: for your turmvilla scenaria it might
help to provide .iso images with a running system (e.g. using
grub-mkrescue) and make them accessible for download. You would then use
dd to copy the image on a USB pendrive or an SD card and reboot your
computer from this external storage device without installing it on your
internal hard drive. You could also use this mechanism to install the
system on your internal hard drive, if you have the capability to
dynamicly resize your partitions, but you wouldn't have to. The way I
see it, a dynamic init component would be a prerequisite.

To say it with the words of Karl Valentin: everything has been said -
just not by everyone.

All the best, Florian.

[Peter Lindener]

Dear
Genodians-

I spent some time catching up on the state of CHERI project
<http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/>..
for the detailed read see: Capability Hardware Enhanced RISC Instructions:
CHERI Instruction-Set Architecture (Version 5)
<http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-891.pdf>...

I sense, that the longer term of CHERI's capability oriented hardware
development will likely unfold in conjunction with the RiscV and / or
LowRisc project's developments..

as the Genode team is already embracing future of running on the RiscV
open ISA... and Genode is also a capability based OS... it would be
great if Genode started tracking / contributing to the Capability bit
field's under development within the CHERI project...

I'm not sure how similar the current Genode and CHERI capability models
are,
... what kind of ajustments each might want to make in order to accomidate
the needs / inovations of the other
I would certainly enjoy reading any reflections in this regard..

-Peter



On Wed, Jan 11, 2017 at 10:54 PM, Dr. Florian Manfred GrÀtz <

Post by Dr. Florian Manfred Grätz
Dear community,
I am very excited about the entire Genode project and looking forward to
the upcoming releases. Please keep up the quaterly release cycle. Let me
- From a newbee's point of view I would say, that you guys are heading
into the right direction: I understand the core component to be a kernel
abstraction layer. Therfore ABI stability of the core would be awsome - no
matter what the kernel is, you could use the same binaries (as long as you
are running on the same processor, of course) for drivers and applications.
That would be a prerequiste for a working packaging system.
- The build process indeed needs a little make-over. I have noticed
side effects with the ports, which are hard to describe in detail, as I
have not yet fully understood them. Generally speaking the ports (including
the drivers) should be built separately from the kernel/core/init. Once
again - a stable ABI would help. No matter what the kernel is, you would
use the same binaries for the drivers/applications.
- A dynamic init component would greatly help, too: reconfigure your
system, don't rebuild it. This would also enhance the turmvilla scenario.
Let me also add an idea of mine: for your turmvilla scenaria it might help
to provide .iso images with a running system (e.g. using grub-mkrescue) and
make them accessible for download. You would then use dd to copy the image
on a USB pendrive or an SD card and reboot your computer from this external
storage device without installing it on your internal hard drive. You could
also use this mechanism to install the system on your internal hard drive,
if you have the capability to dynamicly resize your partitions, but you
wouldn't have to. The way I see it, a dynamic init component would be a
prerequisite.
To say it with the words of Karl Valentin: everything has been said - just
not by everyone.
All the best, Florian.
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Norman Feske]

Hi Florian,

Post by Dr. Florian Manfred Grätz
I am very excited about the entire Genode project and looking forward to
the upcoming releases. Please keep up the quaterly release cycle.

thank you for the encouragement and for sharing your thoughts about the
road map.

Post by Dr. Florian Manfred Grätz
* From a newbee's point of view I would say, that you guys are heading
into the right direction: I understand the core component to be a
kernel abstraction layer. Therfore ABI stability of the core would
be awsome - no matter what the kernel is, you could use the same
binaries (as long as you are running on the same processor, of
course) for drivers and applications. That would be a prerequiste
for a working packaging system.

Technically speaking, the kernel-abstraction layer consists of two
parts, the core component and Genode's base library. For most programs,
the base library has the form of the dynamic linker. Because of this
design, each program interacts with the underlying kernel directly.
Unlike a virtual machine, core represents no indirection between the
kernel and the application code (except for operations that require the
allocation of physical resources that are arbitrated by core).
Therefore, the use of Genode does not add any overhead compared to the
"direct" use of the underlying kernel.

You are perfectly right about the ABI being an enabler for the packaging.

Post by Dr. Florian Manfred Grätz
* The build process indeed needs a little make-over. I have noticed
side effects with the ports, which are hard to describe in detail,
as I have not yet fully understood them. Generally speaking the
ports (including the drivers) should be built separately from the
kernel/core/init. Once again - a stable ABI would help. No matter
what the kernel is, you would use the same binaries for the
drivers/applications.

The upcoming version 17.02 will come with the tooling needed for
building individual packages outside a Genode build system. The tools
put the ABI go good use. I.e., by introducing a libc API package (which
entails both the libc ABI and the headers), it is possible to build
libc-dependent packages without the need to build the libc. The second
piece of the puzzle will be an example Genode system that integrates a
number of packages into a bootable system. At the first stage, this will
still be a fairly static scenario. But as the year progresses, I want
the running system to become increasingly dynamic, e.g., by updating and
running programs on the fly without the need to create a new system
image or the need to reboot.

Post by Dr. Florian Manfred Grätz
* A dynamic init component would greatly help, too: reconfigure your
system, don't rebuild it. This would also enhance the turmvilla
scenario.

Indeed, I see it as the key for the development sketched above.

Post by Dr. Florian Manfred Grätz
Let me also add an idea of mine: for your turmvilla scenaria it might
help to provide .iso images with a running system (e.g. using
grub-mkrescue) and make them accessible for download. You would then use
dd to copy the image on a USB pendrive or an SD card and reboot your
computer from this external storage device without installing it on your
internal hard drive.

Except for the "download" part, this is what the Heeselicht scenario (as
referenced by Ben aka Nobody III) represents. Btw, you can actually copy
the build result of any Genode scenario to a USB stick (when using any
of the microkernels). After building a scenario, you find the
corresponding ISO image at '<build-dir>/var/run/<scenario>.iso'. You may
give this a try with the 'demo.run' script.

Post by Dr. Florian Manfred Grätz
You could also use this mechanism to install the
system on your internal hard drive, if you have the capability to
dynamicly resize your partitions, but you wouldn't have to. The way I
see it, a dynamic init component would be a prerequisite.

This is the picture that I have in mind.

Thanks again for chiming in and for your enthusiasm for Genode! :-)

Cheers
Norman

[Norman Feske]

Hello,

thanks to everyone who participated in the road-map discussion! I have
compiled the official road map now:

https://genode.org/about/road-map

I hope that it captures well our overall discussion.

There are a few topics that were discussed but did not appear on the
official road map (like Johannes' Zynq line of work, Emery's gaming
topic, or Martin's i.MX6 topic). Please don't take this as
discouragement. Those topics are very interesting and valuable but I
felt uneasy to make the road map too much dependent on your individual
plans and thereby needlessly putting pressure on you. I think that it is
better to deliver those features without prior announcement than to
over-promise. Do you agree?

Cheers
Norman

[Johannes Schlatow]

I think that it is better to deliver those features without prior
announcement than to over-promise. Do you agree?

Totally ;-)

[Emery Hemingway]

Post by Johannes Schlatow

I think that it is better to deliver those features without prior
announcement than to over-promise. Do you agree?

Totally ;-)

Yes, I tend to announce more than I see through to the very end :-)