Hello everybody,
with New Year in sight, it is time to make up our minds regarding the plans for 2015. Everyone of you is invited to suggest directions that you find worthwhile to pursue - or even better - share your concrete plans with us. I intend to finalize the road map for 2015 by mid of January.
Personally, I have three ambitions, namely the use of Genode as general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me briefly revisit each of them.
Genode as general-purpose OS ----------------------------
We made big steps for pursuing Genode as general-purpose OS on x86-based platforms. I'd particularly like to highlight the following achievements:
* The use of Rump kernels as file-system providers * VirtualBox with support for shared folders and guest networking * Intel wireless stack * New GUI stack
That said, even though we are proud about the progress, we are still not there yet. So what keeps us back? I think that the answer is actually not technical. My observation is that each of us developers used to concentrate on individual features or technical challenges. But the integration of sophisticated system scenarios was left to only a few of us. Such integration feats were mainly motivated by a particular project or by a presentation. In order to make Genode fit for regular use, we will first need to make the composing of advanced systems a habit for most of the regular developers.
I'd like to keep the topic as first priority in 2015 but concentrate less on features (as I think the feature set for us developers is fairly complete) but more on looking at Genode in a holistic way. I would like to see the following things realized:
* A system booting from USB storage, which contains a VirtualBox instance running a regular Linux-based OS besides native Genode components. A shared folder is to be used to bridge both worlds. We start out with working in the guest OS and then successively move functionalities over to the Genode world. Those functionalities are: * Editing text, e.g., using Vim in a Noux environment * Creating and starting Genode configurations on the fly * Using a web browser in Genode * Moving emails to the Genode world * Use the Genode tool chain * Using Git I expect that we will stumble over several small issues and inconveniences on our way, which gives us the right motivation to rectify those things.
* A way to easily install and use pre-packaged Genode subsystems. I'd like to remove the burden to compile Qt5 + WebKit for everyone who wants to use a web browser on Genode.
* Tools for looking at the system at runtime to identify performance hot spots. I'd love it identify strangely behaving components as easily as running 'top' on Linux.
* A solid solution for platform drivers (supporting MSIs and the hot-plugging of devices). I.e., I'd like to access the content of a plugged-in USB stick without the need to reboot the machine.
* The evolution of our capability-based desktop environment, driven by our actual requirements stemming from the daily use of Genode. The system should be fun to use and put the user in control at all times.
* Making Genode components and libraries binary compatible across different kernels. I see this as a prerequisite to offer binary packages of Genode subsystems. The new dynamic linker introduced in Genode 14.11 is an important step. The next step is the unification of the Genode API across all kernels.
Base-hw kernel --------------
In 2014, our base-hw kernel made the transformation from a research vehicle to a feasible base platform for Genode. The past year brought a huge jump in terms of performance, MP support, a clean internal structure, and a new scheduler.
In 2015 it will eventually become product-quality software. The only missing element is the support for capability-based security, which is being worked on right now. For base-hw, my wish list looks as follows:
* Capability-based security * Integration of our existing ARM virtualization research
seL4 kernel -----------
I feel that the seL4 kernel and Genode could complement each other rather well. The use of seL4 as kernel would make Genode very appealing in application areas where both the kernel's formal verification and Genode's broad feature set are desired. From the perspective of the seL4 developers, Genode would represent the first true microkernel-based general-purpose OS running on their kernel. I would hope that, by supporting seL4 as kernel for Genode, we may create an incentive for both developer teams to start collaborating more closely.
These are my thoughts. I am looking forward to your ideas and comments.
Cheers Norman
On 02/01/15 17:50, Josef Söntgen wrote:
On 01/02/15 15:45, Antti Kantee wrote:
For smb/nfs, you most likely want to implement the sockin_user set of I/O hypercalls which allow the smb/nfs file system drivers from rump kernels to use an external networking stack:
http://nxr.netbsd.org/xref/src/sys/rump/net/lib/libsockin/sockin_user.h?r=1....
Now, that interface wasn't really ever designed to be implemented anywhere except on NetBSD. Nevertheless, we (I think it was Arnaud) managed to cram support for all userspace platforms into the implementation. If you do want to change some aspects of that interface to help it work on Genode, I'm more than happy to do it.
Ah, I really overlooked using the sockin_user interface for this task and rather thought about implementing the virtual nic interface and using the rumpkernel's TCP/IP stack - thanks for pointing out this option. It is definitly a viable possibilty to check out.
Right, doing it on the nic level would work too, but then you'd have to give the rump kernel its own network configuration (IP etc.), which is usually not what you want in a microkernel file server context. In fact, sockin was originally created so that the NFS driver in a rump kernel in userspace could use the existing system network and "just work".
Also, there's a 9p driver for puffs (*), which could theoretically just work on Genode, though it would be a bit awkward; you'd run puffs in a rump kernel server and the mount_9p client in a another server ... :/
Though that would certainly work as well, I think it is more reasonable to implement it directly. 9p is a fairly simple protocol so using the whole rumpkernel stack would be overkill IMHO :)
As much as I like to see my code being used, I agree with you ;)
my two cents, tinted by my own personal world view (I work in the security field) -- I think a great way to showcase Genode's strengths (and the strengths of underlying kernels, such as (soon) seL4) would be to port the chrome browser. It's open source (and unfortunately very large), it's one of the most important programs today, it is already designed for security, and one of its strengths is its sandboxing of components. However, chrome's sandbox is not nearly as strong as it could be, and a capability based system like Genode that can put together the minimal set of necessary components would make a much stronger sandbox. Chrome is already architected properly for this, it would just needed to be ported appropriately with the right platform support.
Chrome's security is among the best in the industry, but it is still regularly defeated in challenges such as the yearly pwn2own contest.
On Mon, Dec 22, 2014 at 1:22 AM, Norman Feske <norman.feske@...1...> wrote:
Hello everybody,
with New Year in sight, it is time to make up our minds regarding the plans for 2015. Everyone of you is invited to suggest directions that you find worthwhile to pursue - or even better - share your concrete plans with us. I intend to finalize the road map for 2015 by mid of January.
Personally, I have three ambitions, namely the use of Genode as general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me briefly revisit each of them.
Genode as general-purpose OS
We made big steps for pursuing Genode as general-purpose OS on x86-based platforms. I'd particularly like to highlight the following achievements:
- The use of Rump kernels as file-system providers
- VirtualBox with support for shared folders and guest networking
- Intel wireless stack
- New GUI stack
That said, even though we are proud about the progress, we are still not there yet. So what keeps us back? I think that the answer is actually not technical. My observation is that each of us developers used to concentrate on individual features or technical challenges. But the integration of sophisticated system scenarios was left to only a few of us. Such integration feats were mainly motivated by a particular project or by a presentation. In order to make Genode fit for regular use, we will first need to make the composing of advanced systems a habit for most of the regular developers.
I'd like to keep the topic as first priority in 2015 but concentrate less on features (as I think the feature set for us developers is fairly complete) but more on looking at Genode in a holistic way. I would like to see the following things realized:
A system booting from USB storage, which contains a VirtualBox instance running a regular Linux-based OS besides native Genode components. A shared folder is to be used to bridge both worlds. We start out with working in the guest OS and then successively move functionalities over to the Genode world. Those functionalities are:
- Editing text, e.g., using Vim in a Noux environment
- Creating and starting Genode configurations on the fly
- Using a web browser in Genode
- Moving emails to the Genode world
- Use the Genode tool chain
- Using Git
I expect that we will stumble over several small issues and inconveniences on our way, which gives us the right motivation to rectify those things.
A way to easily install and use pre-packaged Genode subsystems. I'd like to remove the burden to compile Qt5 + WebKit for everyone who wants to use a web browser on Genode.
Tools for looking at the system at runtime to identify performance hot spots. I'd love it identify strangely behaving components as easily as running 'top' on Linux.
A solid solution for platform drivers (supporting MSIs and the hot-plugging of devices). I.e., I'd like to access the content of a plugged-in USB stick without the need to reboot the machine.
The evolution of our capability-based desktop environment, driven by our actual requirements stemming from the daily use of Genode. The system should be fun to use and put the user in control at all times.
Making Genode components and libraries binary compatible across different kernels. I see this as a prerequisite to offer binary packages of Genode subsystems. The new dynamic linker introduced in Genode 14.11 is an important step. The next step is the unification of the Genode API across all kernels.
Base-hw kernel
In 2014, our base-hw kernel made the transformation from a research vehicle to a feasible base platform for Genode. The past year brought a huge jump in terms of performance, MP support, a clean internal structure, and a new scheduler.
In 2015 it will eventually become product-quality software. The only missing element is the support for capability-based security, which is being worked on right now. For base-hw, my wish list looks as follows:
- Capability-based security
- Integration of our existing ARM virtualization research
seL4 kernel
I feel that the seL4 kernel and Genode could complement each other rather well. The use of seL4 as kernel would make Genode very appealing in application areas where both the kernel's formal verification and Genode's broad feature set are desired. From the perspective of the seL4 developers, Genode would represent the first true microkernel-based general-purpose OS running on their kernel. I would hope that, by supporting seL4 as kernel for Genode, we may create an incentive for both developer teams to start collaborating more closely.
These are my thoughts. I am looking forward to your ideas and comments.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
I myself have been trying to do my own work on making Genode a general-purpose OS, and am willing to contribute a fair amount, however I have always been running into block device issues. The AHCI and ATAPI drivers don't work, and the USB driver isn't working for USB storage. All 3 drivers fail to announce the service "Block". Once these drivers are fixed, I will be able (and more than willing) to provide help in making Genode into a general-purpose OS. After the block device drivers, my second suggestion would be to either create a Nitpicker X server or else to port the main X libraries to Nitpicker. After that, for Genode's first desktop environment, we could port LXQt. It's very lightweight and it's compatible with Qt5. I would be happy to take part in this task. As for Linux, it would be cool to make a kernel-agnostic version of L4Linux. On Dec 22, 2014 10:07 AM, "Tim Newsham" <tim.newsham@...9...> wrote:
my two cents, tinted by my own personal world view (I work in the security field) -- I think a great way to showcase Genode's strengths (and the strengths of underlying kernels, such as (soon) seL4) would be to port the chrome browser. It's open source (and unfortunately very large), it's one of the most important programs today, it is already designed for security, and one of its strengths is its sandboxing of components. However, chrome's sandbox is not nearly as strong as it could be, and a capability based system like Genode that can put together the minimal set of necessary components would make a much stronger sandbox. Chrome is already architected properly for this, it would just needed to be ported appropriately with the right platform support.
Chrome's security is among the best in the industry, but it is still regularly defeated in challenges such as the yearly pwn2own contest.
On Mon, Dec 22, 2014 at 1:22 AM, Norman Feske <norman.feske@...1...> wrote:
Hello everybody,
with New Year in sight, it is time to make up our minds regarding the plans for 2015. Everyone of you is invited to suggest directions that you find worthwhile to pursue - or even better - share your concrete plans with us. I intend to finalize the road map for 2015 by mid of
January.
Personally, I have three ambitions, namely the use of Genode as general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me briefly revisit each of them.
Genode as general-purpose OS
We made big steps for pursuing Genode as general-purpose OS on x86-based platforms. I'd particularly like to highlight the following achievements:
- The use of Rump kernels as file-system providers
- VirtualBox with support for shared folders and guest networking
- Intel wireless stack
- New GUI stack
That said, even though we are proud about the progress, we are still not there yet. So what keeps us back? I think that the answer is actually not technical. My observation is that each of us developers used to concentrate on individual features or technical challenges. But the integration of sophisticated system scenarios was left to only a few of us. Such integration feats were mainly motivated by a particular project or by a presentation. In order to make Genode fit for regular use, we will first need to make the composing of advanced systems a habit for most of the regular developers.
I'd like to keep the topic as first priority in 2015 but concentrate less on features (as I think the feature set for us developers is fairly complete) but more on looking at Genode in a holistic way. I would like to see the following things realized:
A system booting from USB storage, which contains a VirtualBox instance running a regular Linux-based OS besides native Genode components. A shared folder is to be used to bridge both worlds. We start out with working in the guest OS and then successively move functionalities over to the Genode world. Those functionalities are:
- Editing text, e.g., using Vim in a Noux environment
- Creating and starting Genode configurations on the fly
- Using a web browser in Genode
- Moving emails to the Genode world
- Use the Genode tool chain
- Using Git
I expect that we will stumble over several small issues and inconveniences on our way, which gives us the right motivation to rectify those things.
A way to easily install and use pre-packaged Genode subsystems. I'd like to remove the burden to compile Qt5 + WebKit for everyone who wants to use a web browser on Genode.
Tools for looking at the system at runtime to identify performance hot spots. I'd love it identify strangely behaving components as easily as running 'top' on Linux.
A solid solution for platform drivers (supporting MSIs and the hot-plugging of devices). I.e., I'd like to access the content of a plugged-in USB stick without the need to reboot the machine.
The evolution of our capability-based desktop environment, driven by our actual requirements stemming from the daily use of Genode. The system should be fun to use and put the user in control at all times.
Making Genode components and libraries binary compatible across different kernels. I see this as a prerequisite to offer binary packages of Genode subsystems. The new dynamic linker introduced in Genode 14.11 is an important step. The next step is the unification of the Genode API across all kernels.
Base-hw kernel
In 2014, our base-hw kernel made the transformation from a research vehicle to a feasible base platform for Genode. The past year brought a huge jump in terms of performance, MP support, a clean internal structure, and a new scheduler.
In 2015 it will eventually become product-quality software. The only missing element is the support for capability-based security, which is being worked on right now. For base-hw, my wish list looks as follows:
- Capability-based security
- Integration of our existing ARM virtualization research
seL4 kernel
I feel that the seL4 kernel and Genode could complement each other rather well. The use of seL4 as kernel would make Genode very appealing in application areas where both the kernel's formal verification and Genode's broad feature set are desired. From the perspective of the seL4 developers, Genode would represent the first true microkernel-based general-purpose OS running on their kernel. I would hope that, by supporting seL4 as kernel for Genode, we may create an incentive for both developer teams to start collaborating more closely.
These are my thoughts. I am looking forward to your ideas and comments.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Ben,
* Nobody III <hungryninja101@...9...> [2014-12-22 17:54:48 +0000]:
I myself have been trying to do my own work on making Genode a general-purpose OS, and am willing to contribute a fair amount, however I have always been running into block device issues. The AHCI and ATAPI drivers don't work, and the USB driver isn't working for USB storage. All 3 drivers fail to announce the service "Block". Once these drivers are fixed, I will be able (and more than willing) to provide help in making Genode into a general-purpose OS.
I do not want to be rude but there is this saying “if you want something you will find ways and if you do not you will find reasons”. Even if these issues are resolved I will guarantee you there will be others. At one point or another you have to get your hands dirty. I certainly get your point — the problems you are having are showstoppers when using Genode as your daily OS but they should not stop you from exploring Genode or even starting to port some software at this time.
After the block device drivers, my second suggestion would be to either create a Nitpicker X server or else to port the main X libraries to Nitpicker.
Do yourself a favour and do not waste your time by porting X11 to Genode. It is not worth the effort. Everyone is better off w/o it.
After that, for Genode's first desktop environment, we could port LXQt. It's very lightweight and it's compatible with Qt5. I would be happy to take part in this task.
To be honest I would rather not use a “common” desktop enviroment on Genode. I think the DE is vital piece of software and by simply porting an existing one you would probably lose much of the features that make Genode unique. But do not let me stop you — if you want to use LXQt on Genode go for it.
Cheers Josef
Hello Tim,
* Tim Newsham <tim.newsham@...9...> [2014-12-22 07:06:04 -1000]:
my two cents, tinted by my own personal world view (I work in the security field) -- I think a great way to showcase Genode's strengths (and the strengths of underlying kernels, such as (soon) seL4) would be to port the chrome browser. It's open source (and unfortunately very large), it's one of the most important programs today, it is already designed for security, and one of its strengths is its sandboxing of components. However, chrome's sandbox is not nearly as strong as it could be, and a capability based system like Genode that can put together the minimal set of necessary components would make a much stronger sandbox. Chrome is already architected properly for this, it would just needed to be ported appropriately with the right platform support.
I agree, Chrome would be a great showcase, indeed. However, as you already mentioned, it is very large and quite complex — porting it would require much effort. Unfortunately, we currently do not have the time to perform this task. That being said, we are willing to support anyone who tries to port Chrome to Genode as best as we can.
At the moment it would be more feasible to send Arora into an early retirement and use a more modern or atleast actively maintained Qt5 based browser like Qupzilla instead. An older version of it was already ported to Genode by ksys labs and porting the latest stable version should not be that big of a deal.
Cheers Josef
Like Norman, I would like the year 2015 to be “the year of the Genode Desktop” [sic] and focus more closely on refining certain components and completing their functionality, i.e. using multiple USB storage devices at the same time, being able to resize a terminal window, having audio support on newer HDA chipsets to better fit my personal needs and of course the integration of existing components. This way it eventually also gets easier to provide a new live-cd ;-)
Within the meaning of using Genode it might be reasonable to formulate a few specific needs and how to (possibly) address them:
* A reasonably comfortable way to configure and start new subsystems dynamically at run time (as a first step by extending cli_monitor and combing it with noux to create new configurations)
* More natural interaction with files (presenting them in a graphical way by attaching a particular “view” depending on its type)
* Usable E-Mail client appliance (for starters by using the usual mutt+msmtp+isync+gpg setup in isolated noux instances)
* Access to remote resources via network (NFS/SMB in rump_fs could be enabled, a simple protocol like 9p2000 could be implemented)
* Being able to browse the “modern” web on Genode (though we have Arora, porting an actively maintained browser like Qupzilla is worthwhile, imho — sadly lynx does not count anymore in this day and age) (*)
Cheers Josef
(*) On that account, there is several Qt5 based applications like mumble, phototonic, transmission, vlc and so on, which should be fairly easy to port to Genode and might serve as a stop-gap solution for particular tasks.
On 22/12/14 21:52, Josef Söntgen wrote:
- Access to remote resources via network (NFS/SMB in rump_fs could be enabled, a simple protocol like 9p2000 could be implemented)
For smb/nfs, you most likely want to implement the sockin_user set of I/O hypercalls which allow the smb/nfs file system drivers from rump kernels to use an external networking stack:
http://nxr.netbsd.org/xref/src/sys/rump/net/lib/libsockin/sockin_user.h?r=1....
Now, that interface wasn't really ever designed to be implemented anywhere except on NetBSD. Nevertheless, we (I think it was Arnaud) managed to cram support for all userspace platforms into the implementation. If you do want to change some aspects of that interface to help it work on Genode, I'm more than happy to do it.
Also, there's a 9p driver for puffs (*), which could theoretically just work on Genode, though it would be a bit awkward; you'd run puffs in a rump kernel server and the mount_9p client in a another server ... :/
*) http://nxr.netbsd.org/xref/src/usr.sbin/puffs/mount_9p/
- antti
It might be easier to port the Linux SMB utilities (e.g. mount.cifs, which uses fuse). On Jan 2, 2015 7:50 AM, "Antti Kantee" <pooka@...279...> wrote:
On 22/12/14 21:52, Josef Söntgen wrote:
- Access to remote resources via network (NFS/SMB in rump_fs could be enabled, a simple protocol like 9p2000 could be implemented)
For smb/nfs, you most likely want to implement the sockin_user set of I/O hypercalls which allow the smb/nfs file system drivers from rump kernels to use an external networking stack:
http://nxr.netbsd.org/xref/src/sys/rump/net/lib/libsockin/sockin_user.h?r=1....
Now, that interface wasn't really ever designed to be implemented anywhere except on NetBSD. Nevertheless, we (I think it was Arnaud) managed to cram support for all userspace platforms into the implementation. If you do want to change some aspects of that interface to help it work on Genode, I'm more than happy to do it.
Also, there's a 9p driver for puffs (*), which could theoretically just work on Genode, though it would be a bit awkward; you'd run puffs in a rump kernel server and the mount_9p client in a another server ... :/
*) http://nxr.netbsd.org/xref/src/usr.sbin/puffs/mount_9p/
- antti
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
On 01/02/15 15:45, Antti Kantee wrote:
For smb/nfs, you most likely want to implement the sockin_user set of I/O hypercalls which allow the smb/nfs file system drivers from rump kernels to use an external networking stack:
http://nxr.netbsd.org/xref/src/sys/rump/net/lib/libsockin/sockin_user.h?r=1....
Now, that interface wasn't really ever designed to be implemented anywhere except on NetBSD. Nevertheless, we (I think it was Arnaud) managed to cram support for all userspace platforms into the implementation. If you do want to change some aspects of that interface to help it work on Genode, I'm more than happy to do it.
Ah, I really overlooked using the sockin_user interface for this task and rather thought about implementing the virtual nic interface and using the rumpkernel's TCP/IP stack - thanks for pointing out this option. It is definitly a viable possibilty to check out.
Also, there's a 9p driver for puffs (*), which could theoretically just work on Genode, though it would be a bit awkward; you'd run puffs in a rump kernel server and the mount_9p client in a another server ... :/
Though that would certainly work as well, I think it is more reasonable to implement it directly. 9p is a fairly simple protocol so using the whole rumpkernel stack would be overkill IMHO :)
Greetings fellow Genodians- Norman, I like where Genode is going!
I currently run my copy of Win7 inside or VirtualBox hosted via Mint Linux 17... it's unfortunate that full support for VBox guest USB access (I gather) requires the instillation of Oracle's VirtualBox Extension Pack https://www.virtualbox.org/wiki/Downloads that is full of "less trusted" proprietary driver code.....
it would be great if the shift to use Genode as my day to day OS foundation...might help people move beyond depending on the portion of VirtualBox code that is "less than fully open" ..
more so, if the VirtualBox code base ever happened to do something "less than trustworthy".... it would be great if the Gnode OS would be likely to catch it in the act of doing so.. such that we might be able to catch and fix any security flaws that might exist in VirtualBox's open source code base...
It would be good if somehow Docker and/or CoreOS containers might be able to run applications in a fairly light weight, but securely contained environment ( i.e.Network firewall, selective access file system ) under Genode...
My sense is that support for x11 would be a compleat wast of energie...but studying how Nitpicker might want to evolve to acomidate the Wayland display server API would likely be a very good thing for Genode's longer term future... much of this display system adjustment might already be accommodated via Qt5.... so this might be faily easy to navigate..
Great to hear that Genode's future sound bright...I'm looking forward to it! -Peter
On Mon, Dec 22, 2014 at 3:22 AM, Norman Feske <norman.feske@...1...> wrote:
Hello everybody,
with New Year in sight, it is time to make up our minds regarding the plans for 2015. Everyone of you is invited to suggest directions that you find worthwhile to pursue - or even better - share your concrete plans with us. I intend to finalize the road map for 2015 by mid of January.
Personally, I have three ambitions, namely the use of Genode as general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me briefly revisit each of them.
Genode as general-purpose OS
We made big steps for pursuing Genode as general-purpose OS on x86-based platforms. I'd particularly like to highlight the following achievements:
- The use of Rump kernels as file-system providers
- VirtualBox with support for shared folders and guest networking
- Intel wireless stack
- New GUI stack
That said, even though we are proud about the progress, we are still not there yet. So what keeps us back? I think that the answer is actually not technical. My observation is that each of us developers used to concentrate on individual features or technical challenges. But the integration of sophisticated system scenarios was left to only a few of us. Such integration feats were mainly motivated by a particular project or by a presentation. In order to make Genode fit for regular use, we will first need to make the composing of advanced systems a habit for most of the regular developers.
I'd like to keep the topic as first priority in 2015 but concentrate less on features (as I think the feature set for us developers is fairly complete) but more on looking at Genode in a holistic way. I would like to see the following things realized:
A system booting from USB storage, which contains a VirtualBox instance running a regular Linux-based OS besides native Genode components. A shared folder is to be used to bridge both worlds. We start out with working in the guest OS and then successively move functionalities over to the Genode world. Those functionalities are:
- Editing text, e.g., using Vim in a Noux environment
- Creating and starting Genode configurations on the fly
- Using a web browser in Genode
- Moving emails to the Genode world
- Use the Genode tool chain
- Using Git
I expect that we will stumble over several small issues and inconveniences on our way, which gives us the right motivation to rectify those things.
A way to easily install and use pre-packaged Genode subsystems. I'd like to remove the burden to compile Qt5 + WebKit for everyone who wants to use a web browser on Genode.
Tools for looking at the system at runtime to identify performance hot spots. I'd love it identify strangely behaving components as easily as running 'top' on Linux.
A solid solution for platform drivers (supporting MSIs and the hot-plugging of devices). I.e., I'd like to access the content of a plugged-in USB stick without the need to reboot the machine.
The evolution of our capability-based desktop environment, driven by our actual requirements stemming from the daily use of Genode. The system should be fun to use and put the user in control at all times.
Making Genode components and libraries binary compatible across different kernels. I see this as a prerequisite to offer binary packages of Genode subsystems. The new dynamic linker introduced in Genode 14.11 is an important step. The next step is the unification of the Genode API across all kernels.
Base-hw kernel
In 2014, our base-hw kernel made the transformation from a research vehicle to a feasible base platform for Genode. The past year brought a huge jump in terms of performance, MP support, a clean internal structure, and a new scheduler.
In 2015 it will eventually become product-quality software. The only missing element is the support for capability-based security, which is being worked on right now. For base-hw, my wish list looks as follows:
- Capability-based security
- Integration of our existing ARM virtualization research
seL4 kernel
I feel that the seL4 kernel and Genode could complement each other rather well. The use of seL4 as kernel would make Genode very appealing in application areas where both the kernel's formal verification and Genode's broad feature set are desired. From the perspective of the seL4 developers, Genode would represent the first true microkernel-based general-purpose OS running on their kernel. I would hope that, by supporting seL4 as kernel for Genode, we may create an incentive for both developer teams to start collaborating more closely.
These are my thoughts. I am looking forward to your ideas and comments.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Sorry, but I have no experience with coding drivers, and I'm unfamiliar with the relevant hardware interfaces. As for AHCI, after recording a video of Genode's output (serial communication isn't working), I found that it does annonce sevice "Block", however part_blk doesn't give any output whatsoever when trying to use AHCI's block service. I started another email thread about it. Any help would be great. Thanks for the tip about not porting X11.
On Mon, Dec 22, 2014 at 11:03 PM, Peter Lindener <lindener.peter@...9...> wrote:
Greetings fellow Genodians- Norman, I like where Genode is going!
I currently run my copy of Win7 inside or VirtualBox hosted via MintLinux 17... it's unfortunate that full support for VBox guest USB access (I gather) requires the instillation of Oracle's VirtualBox Extension Pack https://www.virtualbox.org/wiki/Downloads that is full of "less trusted" proprietary driver code.....
it would be great if the shift to use Genode as my day to day OS foundation...might help people move beyond depending on the portion of VirtualBox code that is "less than fully open" ..
more so, if the VirtualBox code base ever happened to do something "less than trustworthy".... it would be great if the Gnode OS would be likely to catch it in the act of doing so.. such that we might be able to catch and fix any security flaws that might exist in VirtualBox's open source code base...
It would be good if somehow Docker and/or CoreOS containers might be able to run applications in a fairly light weight, but securely contained environment ( i.e.Network firewall, selective access file system ) under Genode...
My sense is that support for x11 would be a compleat wast of energie...but studying how Nitpicker might want to evolve to acomidate the Wayland display server API would likely be a very good thing for Genode's longer term future... much of this display system adjustment might already be accommodated via Qt5.... so this might be faily easy to navigate..
Great to hear that Genode's future sound bright...I'm looking forwardto it! -Peter
On Mon, Dec 22, 2014 at 3:22 AM, Norman Feske < norman.feske@...1...> wrote:
Hello everybody,
with New Year in sight, it is time to make up our minds regarding the plans for 2015. Everyone of you is invited to suggest directions that you find worthwhile to pursue - or even better - share your concrete plans with us. I intend to finalize the road map for 2015 by mid of January.
Personally, I have three ambitions, namely the use of Genode as general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me briefly revisit each of them.
Genode as general-purpose OS
We made big steps for pursuing Genode as general-purpose OS on x86-based platforms. I'd particularly like to highlight the following achievements:
- The use of Rump kernels as file-system providers
- VirtualBox with support for shared folders and guest networking
- Intel wireless stack
- New GUI stack
That said, even though we are proud about the progress, we are still not there yet. So what keeps us back? I think that the answer is actually not technical. My observation is that each of us developers used to concentrate on individual features or technical challenges. But the integration of sophisticated system scenarios was left to only a few of us. Such integration feats were mainly motivated by a particular project or by a presentation. In order to make Genode fit for regular use, we will first need to make the composing of advanced systems a habit for most of the regular developers.
I'd like to keep the topic as first priority in 2015 but concentrate less on features (as I think the feature set for us developers is fairly complete) but more on looking at Genode in a holistic way. I would like to see the following things realized:
A system booting from USB storage, which contains a VirtualBox instance running a regular Linux-based OS besides native Genode components. A shared folder is to be used to bridge both worlds. We start out with working in the guest OS and then successively move functionalities over to the Genode world. Those functionalities are:
- Editing text, e.g., using Vim in a Noux environment
- Creating and starting Genode configurations on the fly
- Using a web browser in Genode
- Moving emails to the Genode world
- Use the Genode tool chain
- Using Git
I expect that we will stumble over several small issues and inconveniences on our way, which gives us the right motivation to rectify those things.
A way to easily install and use pre-packaged Genode subsystems. I'd like to remove the burden to compile Qt5 + WebKit for everyone who wants to use a web browser on Genode.
Tools for looking at the system at runtime to identify performance hot spots. I'd love it identify strangely behaving components as easily as running 'top' on Linux.
A solid solution for platform drivers (supporting MSIs and the hot-plugging of devices). I.e., I'd like to access the content of a plugged-in USB stick without the need to reboot the machine.
The evolution of our capability-based desktop environment, driven by our actual requirements stemming from the daily use of Genode. The system should be fun to use and put the user in control at all times.
Making Genode components and libraries binary compatible across different kernels. I see this as a prerequisite to offer binary packages of Genode subsystems. The new dynamic linker introduced in Genode 14.11 is an important step. The next step is the unification of the Genode API across all kernels.
Base-hw kernel
In 2014, our base-hw kernel made the transformation from a research vehicle to a feasible base platform for Genode. The past year brought a huge jump in terms of performance, MP support, a clean internal structure, and a new scheduler.
In 2015 it will eventually become product-quality software. The only missing element is the support for capability-based security, which is being worked on right now. For base-hw, my wish list looks as follows:
- Capability-based security
- Integration of our existing ARM virtualization research
seL4 kernel
I feel that the seL4 kernel and Genode could complement each other rather well. The use of seL4 as kernel would make Genode very appealing in application areas where both the kernel's formal verification and Genode's broad feature set are desired. From the perspective of the seL4 developers, Genode would represent the first true microkernel-based general-purpose OS running on their kernel. I would hope that, by supporting seL4 as kernel for Genode, we may create an incentive for both developer teams to start collaborating more closely.
These are my thoughts. I am looking forward to your ideas and comments.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello,
thanks Norman for starting this already fruitful discussion right before the holidays - I'm looking forward to all the messages from the community.
Beside the desktop environment and pushing the exciting ideas of a data-centric approach for our user interface I see further challenges in the field of networking. With LAN and WiFi access on a good path, we should invest more time into network interoperability. First, the good old NIC bridge needs a companion NAT service as environments like hotel WLANs are not that generous with multiple IP addresses per client. Next, the new NAT component as well as existing services and drivers need to become adaptable and sensitive to changing network environments - also a manual approach would be feasible IMO.
Further (as Josef and Ben also brought up), the user interface to network services must be enabled. I would be more than glad with good old mutt plus IMAP sync and Chrome on Genode. Especially the latter sounds like a worthwhile challenge.
Greets and Happy holidays
One request that I myself am not very capable of helping with is USB WiFi. Could we maybe add that to the list?
On Tue, Dec 23, 2014 at 9:36 PM, Christian Helmuth < christian.helmuth@...1...> wrote:
Hello,
thanks Norman for starting this already fruitful discussion right before the holidays - I'm looking forward to all the messages from the community.
Beside the desktop environment and pushing the exciting ideas of a data-centric approach for our user interface I see further challenges in the field of networking. With LAN and WiFi access on a good path, we should invest more time into network interoperability. First, the good old NIC bridge needs a companion NAT service as environments like hotel WLANs are not that generous with multiple IP addresses per client. Next, the new NAT component as well as existing services and drivers need to become adaptable and sensitive to changing network environments - also a manual approach would be feasible IMO.
Further (as Josef and Ben also brought up), the user interface to network services must be enabled. I would be more than glad with good old mutt plus IMAP sync and Chrome on Genode. Especially the latter sounds like a worthwhile challenge.
Greets and Happy holidays
Christian Helmuth Genode Labs
http://www.genode-labs.com/ · http://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
On December 23, 2014 11:27:24 PM CET, Nobody III <hungryninja101@...9...> wrote:
One request that I myself am not very capable of helping with is USB WiFi. Could we maybe add that to the list?
Anyway, I suggest you to give it try: identify the driver for your device in Linux, add it to DDE Linux, and give it a spin. I have no hands-on experience with USB WiFi but would support such an activity. Are there many differing chipsets or could we identify one family of dongles that are wide spread?
Regards
The main chipset that I would like to see supported is RTL8812AU. The linux driver isn't part of the mainstream kernel, but it's available on github at https://github.com/scrivy/rtl8812AU_8821AU_linux. How exactly do I use this?
On Wed, Dec 24, 2014 at 10:54 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
Hi,
On December 23, 2014 11:27:24 PM CET, Nobody III <hungryninja101@...9...> wrote:
One request that I myself am not very capable of helping with is USB WiFi. Could we maybe add that to the list?
Anyway, I suggest you to give it try: identify the driver for your device in Linux, add it to DDE Linux, and give it a spin. I have no hands-on experience with USB WiFi but would support such an activity. Are there many differing chipsets or could we identify one family of dongles that are wide spread?
Regards
Christian Helmuth Genode Labs
http://www.genode-labs.com/ · http://genode.org/ · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi all,
sorry for the delay, but speaking of NAT components that spare IP addresses, I wanted to make you guys aware of my diploma thesis which treated exactly that topic, albeit on Linux:
http://os.inf.tu-dresden.de/papers_ps/unzner-diplom.pdf
In contrast to the source code that I wrote back then, for Genode, we would require a C++ solution which does not need Rump kernel patches (as that is not feasible in the long run) and performs a lot better. Also, unit and integration tests are missing, and by now I think they are a must-have.
My code base is quite small already, so all these issues call for a rewrite. I will see how far I can get with that effort, but it being a spare-time project of mine it is possible that I do not get anywhere at all.
Hence, if somebody wanted to work in that direction I would be glad to support them.
Cheers!
Martin
Am 23.12.2014 um 22:36 schrieb Christian Helmuth:
Hello,
thanks Norman for starting this already fruitful discussion right before the holidays - I'm looking forward to all the messages from the community.
Beside the desktop environment and pushing the exciting ideas of a data-centric approach for our user interface I see further challenges in the field of networking. With LAN and WiFi access on a good path, we should invest more time into network interoperability. First, the good old NIC bridge needs a companion NAT service as environments like hotel WLANs are not that generous with multiple IP addresses per client. Next, the new NAT component as well as existing services and drivers need to become adaptable and sensitive to changing network environments - also a manual approach would be feasible IMO.
Further (as Josef and Ben also brought up), the user interface to network services must be enabled. I would be more than glad with good old mutt plus IMAP sync and Chrome on Genode. Especially the latter sounds like a worthwhile challenge.
Greets and Happy holidays
Hello Martin,
On Mon, Jan 05, 2015 at 09:59:05PM +0100, Martin Unzner wrote:
sorry for the delay, but speaking of NAT components that spare IP addresses, I wanted to make you guys aware of my diploma thesis which treated exactly that topic, albeit on Linux:
Many thanks for mentioning your work again - it was somewhere in the back of my head but ...
My code base is quite small already, so all these issues call for a rewrite. I will see how far I can get with that effort, but it being a spare-time project of mine it is possible that I do not get anywhere at all.
Hence, if somebody wanted to work in that direction I would be glad to support them.
Do you think it would be feasible to provide your current implementation and link it in
https://github.com/genodelabs/genode/issues/114
as an alternative approach? This could be the initial ignition for a joint spare-time project.
Greets
Hi,
i would propose something quite boring:
Automated tests of each component and script and giving the results on a web page so one can easily see if everything is up and running together with an update of the documentation.
Why?
As I tried out genode I ran in a few issues. Some needed a fix from your site, some are never fixed (e.g. last problems between blkcache and rumpfs, last mail form Stefen Kalkowski with :" Well, I've tested the scenario on a "real" ext2 partition too, and observed the corruption of the filesystem with and without the blk_cache. Therefore, I assume it isn't related to the cache, but to the rump fs server, or it's usage.")
This means at the moment if I use something and anything goes wrong there are many possible suspects: - Documentation is outdated. - Documentation has something missing which is written in some release note/documentation - Information from last release note is also already outdated - I have done something wrong - some component does not work as expected (e.g. from time to time you read "haven't used it for some time, script no longer works") - problem with the correct setup or the way components work together.
Every issue with a component can be a possible security bug.
Benefits: - Updates of the documentation will help other developers or people just trying out the system - Test scripts and reacting on the results will produce a system which is more stable
How? First minimal step: - set up a continues integration system. - create at least one test for every component ( later: create unit tests to test e.g. every path, null values, wrong values and so on, but for start just do a test which tests the expected behaviour of the system. ) - create an easy to view output, e.g. Component | Red-Green (leading to a finer granulated page with Component | Test | Red-Green | Error output) With the automated run after a check in you can see wether a component still runs after changes (Later: auto reject changes which lead to failed runs). That leads to 2 major things: - Third party developers can see wether a component is generally usable - As it is clear which action lead to a failed run the bug can be found faster and the time to fix shoudl be lower
Best regards Wolfgang
-----Ursprüngliche Nachricht----- From: Norman Feske Sent: Monday, December 22, 2014 12:22 PM To: Genode OS Framework Mailing List Subject: Roadmap 2015
Hello everybody,
with New Year in sight, it is time to make up our minds regarding the plans for 2015. Everyone of you is invited to suggest directions that you find worthwhile to pursue - or even better - share your concrete plans with us. I intend to finalize the road map for 2015 by mid of January.
Personally, I have three ambitions, namely the use of Genode as general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me briefly revisit each of them.
Genode as general-purpose OS ----------------------------
We made big steps for pursuing Genode as general-purpose OS on x86-based platforms. I'd particularly like to highlight the following achievements:
* The use of Rump kernels as file-system providers * VirtualBox with support for shared folders and guest networking * Intel wireless stack * New GUI stack
That said, even though we are proud about the progress, we are still not there yet. So what keeps us back? I think that the answer is actually not technical. My observation is that each of us developers used to concentrate on individual features or technical challenges. But the integration of sophisticated system scenarios was left to only a few of us. Such integration feats were mainly motivated by a particular project or by a presentation. In order to make Genode fit for regular use, we will first need to make the composing of advanced systems a habit for most of the regular developers.
I'd like to keep the topic as first priority in 2015 but concentrate less on features (as I think the feature set for us developers is fairly complete) but more on looking at Genode in a holistic way. I would like to see the following things realized:
* A system booting from USB storage, which contains a VirtualBox instance running a regular Linux-based OS besides native Genode components. A shared folder is to be used to bridge both worlds. We start out with working in the guest OS and then successively move functionalities over to the Genode world. Those functionalities are: * Editing text, e.g., using Vim in a Noux environment * Creating and starting Genode configurations on the fly * Using a web browser in Genode * Moving emails to the Genode world * Use the Genode tool chain * Using Git I expect that we will stumble over several small issues and inconveniences on our way, which gives us the right motivation to rectify those things.
* A way to easily install and use pre-packaged Genode subsystems. I'd like to remove the burden to compile Qt5 + WebKit for everyone who wants to use a web browser on Genode.
* Tools for looking at the system at runtime to identify performance hot spots. I'd love it identify strangely behaving components as easily as running 'top' on Linux.
* A solid solution for platform drivers (supporting MSIs and the hot-plugging of devices). I.e., I'd like to access the content of a plugged-in USB stick without the need to reboot the machine.
* The evolution of our capability-based desktop environment, driven by our actual requirements stemming from the daily use of Genode. The system should be fun to use and put the user in control at all times.
* Making Genode components and libraries binary compatible across different kernels. I see this as a prerequisite to offer binary packages of Genode subsystems. The new dynamic linker introduced in Genode 14.11 is an important step. The next step is the unification of the Genode API across all kernels.
Base-hw kernel --------------
In 2014, our base-hw kernel made the transformation from a research vehicle to a feasible base platform for Genode. The past year brought a huge jump in terms of performance, MP support, a clean internal structure, and a new scheduler.
In 2015 it will eventually become product-quality software. The only missing element is the support for capability-based security, which is being worked on right now. For base-hw, my wish list looks as follows:
* Capability-based security * Integration of our existing ARM virtualization research
seL4 kernel -----------
I feel that the seL4 kernel and Genode could complement each other rather well. The use of seL4 as kernel would make Genode very appealing in application areas where both the kernel's formal verification and Genode's broad feature set are desired. From the perspective of the seL4 developers, Genode would represent the first true microkernel-based general-purpose OS running on their kernel. I would hope that, by supporting seL4 as kernel for Genode, we may create an incentive for both developer teams to start collaborating more closely.
These are my thoughts. I am looking forward to your ideas and comments.
Cheers Norman
I second that suggestion. On Dec 24, 2014 1:48 AM, "Wolfgang Schmidt" <wolfgang.schmidt@...243...> wrote:
Hi,
i would propose something quite boring:
Automated tests of each component and script and giving the results on a web page so one can easily see if everything is up and running together with an update of the documentation.
Why?
As I tried out genode I ran in a few issues. Some needed a fix from your site, some are never fixed (e.g. last problems between blkcache and rumpfs, last mail form Stefen Kalkowski with :" Well, I've tested the scenario on a "real" ext2 partition too, and observed the corruption of the filesystem with and without the blk_cache. Therefore, I assume it isn't related to the cache, but to the rump fs server, or it's usage.")
This means at the moment if I use something and anything goes wrong there are many possible suspects:
- Documentation is outdated.
- Documentation has something missing which is written in some release
note/documentation
- Information from last release note is also already outdated
- I have done something wrong
- some component does not work as expected (e.g. from time to time you read
"haven't used it for some time, script no longer works")
- problem with the correct setup or the way components work together.
Every issue with a component can be a possible security bug.
Benefits:
- Updates of the documentation will help other developers or people just
trying out the system
- Test scripts and reacting on the results will produce a system which is
more stable
How? First minimal step:
- set up a continues integration system.
- create at least one test for every component ( later: create unit tests
to test e.g. every path, null values, wrong values and so on, but for start just do a test which tests the expected behaviour of the system. )
- create an easy to view output, e.g. Component | Red-Green (leading to a finer granulated page with Component | Test | Red-Green |
Error output) With the automated run after a check in you can see wether a component still runs after changes (Later: auto reject changes which lead to failed runs). That leads to 2 major things:
- Third party developers can see wether a component is generally usable
- As it is clear which action lead to a failed run the bug can be found
faster and the time to fix shoudl be lower
Best regards Wolfgang
-----Ursprüngliche Nachricht----- From: Norman Feske Sent: Monday, December 22, 2014 12:22 PM To: Genode OS Framework Mailing List Subject: Roadmap 2015
Hello everybody,
with New Year in sight, it is time to make up our minds regarding the plans for 2015. Everyone of you is invited to suggest directions that you find worthwhile to pursue - or even better - share your concrete plans with us. I intend to finalize the road map for 2015 by mid of January.
Personally, I have three ambitions, namely the use of Genode as general-purpose OS, the base-hw kernel, and the seL4 kernel. Let me briefly revisit each of them.
Genode as general-purpose OS
We made big steps for pursuing Genode as general-purpose OS on x86-based platforms. I'd particularly like to highlight the following achievements:
- The use of Rump kernels as file-system providers
- VirtualBox with support for shared folders and guest networking
- Intel wireless stack
- New GUI stack
That said, even though we are proud about the progress, we are still not there yet. So what keeps us back? I think that the answer is actually not technical. My observation is that each of us developers used to concentrate on individual features or technical challenges. But the integration of sophisticated system scenarios was left to only a few of us. Such integration feats were mainly motivated by a particular project or by a presentation. In order to make Genode fit for regular use, we will first need to make the composing of advanced systems a habit for most of the regular developers.
I'd like to keep the topic as first priority in 2015 but concentrate less on features (as I think the feature set for us developers is fairly complete) but more on looking at Genode in a holistic way. I would like to see the following things realized:
A system booting from USB storage, which contains a VirtualBox instance running a regular Linux-based OS besides native Genode components. A shared folder is to be used to bridge both worlds. We start out with working in the guest OS and then successively move functionalities over to the Genode world. Those functionalities are:
- Editing text, e.g., using Vim in a Noux environment
- Creating and starting Genode configurations on the fly
- Using a web browser in Genode
- Moving emails to the Genode world
- Use the Genode tool chain
- Using Git
I expect that we will stumble over several small issues and inconveniences on our way, which gives us the right motivation to rectify those things.
A way to easily install and use pre-packaged Genode subsystems. I'd like to remove the burden to compile Qt5 + WebKit for everyone who wants to use a web browser on Genode.
Tools for looking at the system at runtime to identify performance hot spots. I'd love it identify strangely behaving components as easily as running 'top' on Linux.
A solid solution for platform drivers (supporting MSIs and the hot-plugging of devices). I.e., I'd like to access the content of a plugged-in USB stick without the need to reboot the machine.
The evolution of our capability-based desktop environment, driven by our actual requirements stemming from the daily use of Genode. The system should be fun to use and put the user in control at all times.
Making Genode components and libraries binary compatible across different kernels. I see this as a prerequisite to offer binary packages of Genode subsystems. The new dynamic linker introduced in Genode 14.11 is an important step. The next step is the unification of the Genode API across all kernels.
Base-hw kernel
In 2014, our base-hw kernel made the transformation from a research vehicle to a feasible base platform for Genode. The past year brought a huge jump in terms of performance, MP support, a clean internal structure, and a new scheduler.
In 2015 it will eventually become product-quality software. The only missing element is the support for capability-based security, which is being worked on right now. For base-hw, my wish list looks as follows:
- Capability-based security
- Integration of our existing ARM virtualization research
seL4 kernel
I feel that the seL4 kernel and Genode could complement each other rather well. The use of seL4 as kernel would make Genode very appealing in application areas where both the kernel's formal verification and Genode's broad feature set are desired. From the perspective of the seL4 developers, Genode would represent the first true microkernel-based general-purpose OS running on their kernel. I would hope that, by supporting seL4 as kernel for Genode, we may create an incentive for both developer teams to start collaborating more closely.
These are my thoughts. I am looking forward to your ideas and comments.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Wolfgang,
* Wolfgang Schmidt <wolfgang.schmidt@...243...> [2014-12-24 09:28:03 +0100]:
i would propose something quite boring:
Automated tests of each component and script and giving the results on a web page so one can easily see if everything is up and running together with an update of the documentation.
Why? […]
This means at the moment if I use something and anything goes wrong there are many possible suspects:
- Documentation is outdated.
- Documentation has something missing which is written in some release
note/documentation
- Information from last release note is also already outdated
- I have done something wrong
- some component does not work as expected (e.g. from time to time you read
"haven't used it for some time, script no longer works")
- problem with the correct setup or the way components work together.
Every issue with a component can be a possible security bug. […]
How? […]
Actually, it is not boring at all so let me elaborate on this topic in more detail for a moment :-)
As a matter of fact we are already employing some kind of CI and run automated tests. Every night the current staging branch is built and most of all run scripts are executed in Qemu as well as on a variety of real machines (¹). Thereby we are promptly notified if something does not build properly for and/or does not run well on a specific platform. Most of the time we can isolate and fix the problem quickly.
In our experience and obviously yours problems arise if you try to use components in a way that is not very well tested. This includes more sophisticated scenarios as well as using drivers on untested hw. To mitigate the problems one needs to do more extensive testing. On the scenario part that is exactly the problem we want to address.
As Norman remarked in his E-Mail, so far we have usually focused our time on creating components for a particular scenario and arranging them to perform a certain task. Since time is what we mainly lack most not all components are as well tested as we would like them to be. The components which basically form the foundation of Genode (base and os) are getting preferential treatment in that regard, though. That said, the more you move away from the components that form the foundation, the more it gets difficult for us to test them and it is more likely that the component in question “does not get much love”. For instance drivers are a problem because we can only test them on hw we actually have at our disposal. That is the part where it is instrumental and more than welcome to have the community test them on unknown hw. Therefore, if someone reports a problem we try to fix it as time permitts. To simplify this process it is helpful to provide as much information as possible (used version of Genode, kernel, …) (²).
Now, at this point let us talk about the documentation since it should help a user to provide the information and to use the system and OTOH a developer to work with Genode. To sum up your remarks about it I would call the current stage merely inconvenient regarding its accessability. The API description mostly deals with the foundation of Genode whereas most features are described in the release notes. This makes accessing the information one seeks arguably laborious. It also is to some extend only valid for the corresponding master branch (³). (To be honest, I personally look more at the source code than the actual documentation itself and therefore do not know at which point it currently is outdated). If the real documentation(⁴) is out-dated or inaccurate, please point out where so we can fix it. Likewise, if there is something that is not as clear as it should be, I encourage you to bring it to our attention.
All in all reading your and the other E-Mails regarding this topic, I think we are on the right track for planing the next year. We already discussed internally to provide access to our buildbot and autopilot log files for the Genode community which apparently is desired. Making the system as a whole more accessible goes hand in hand with addressing the currently voiced issues.
Cheers Josef
(¹) To get a bit more technical we use the well-known buildbot tool for building all components and use our own autopilot tool afterwards to execute the scenarios. The testing facility consists of several ARM boards (among others, Arndale, Panda boards and by now even a RPI) as well as a few common x86 machines ranging from older c2d to i-core series 3rd generation hw.
(²) In that regard I treat a log file of the executed scenario as mandatory and the used run script as sufficient information. Providing the run script enables us to examine the issue more directly and on certain accounts it can be turned into a regression test.
(³) Therefore it makes the life of an developer easier if he/she works with the master branch only.
(⁴) Altough we document the current state of Genode comprehensively in the release notes, these are merely a timed snapshot that tend to be treated as documentation, IMHO.
PS:
Regarding your problems with the blkcache and rump_fs, we are aware of certain issues with this combination and the reason why it is not already fixed is, alas, simply a lack of time and priority. We do not trigger this behaviour in our current use cases or — for better or the worse — are able to mitigate its effects, therefore it gets a low priority. Since it has a low priority someone will eventually work on fixing it when time permitts. Sure — that is suboptimal but that is sadly just the way it (currently) is. Well in any case, rest assure that it has a higher priority by now.
Hi Wolfgang,
thanks for having taking the time to summarize the stumbling blocks you encountered. Your request is very much in line with my ambitions.
As Martin already mentioned, there is already an automated testing infrastructure in place. All the run scripts listed in tool/autopilot.list are executed on various kernels/boards every night - all in all there are about 700 test runs. So far, however, these tests were not visible for the public. From your mail, I get that there is indeed interest from the community in this "boring" topic. So it seems worthwhile to explore a way to open up the test environment.
Admittedly, the ambition to test all components goes beyond our capacities. I agree, though, that the tests should cover the fundamental components, i.e., those hosted in the base and os repositories. That said, I think that extending the coverage of our tests is unlikely to remove the stumbling blocks you encountered - simply because the tests won't cover many combinations of components.
This means at the moment if I use something and anything goes wrong there are many possible suspects:
- Documentation is outdated.
- Documentation has something missing which is written in some release
note/documentation
- Information from last release note is also already outdated
We need to know about those kind of issues. So far, however, we got almost no reports about stale documentation. If you encounter outdated documentation, please open a bug in the issue tracker or drop a note to the mailing list. I really wonder how often this is a problem for Genode users?
- I have done something wrong
- some component does not work as expected (e.g. from time to time you read
"haven't used it for some time, script no longer works")
It is a matter of fact that not all components and run scripts are considered as important by us regular developers. I.e., many run scripts are just vehicles for the respective developer to work on a particular component. The same goes for some components, which are just experimental. They are worth having at hand from time to time but they receive no attention otherwise. I think that this is perfectly fine.
What I take from your report, however, is that we should more clearly mark the line between run scripts and components that we deem as exemplary and stable, and those that are experimental/work-in-progress.
Then again, the experimental components are certainly the ones people like to play with as these are often prominently featured in the release notes. ;-)
To sum it up, with regard to the road map, we should consider:
* Opening up our automated test environment
* Finding a way to tell stable components apart from experimental ones
Cheers Norman
Hello,
I finalized the official road map for this year. Thanks to everyone who contributed to the discussion!
http://genode.org/about/road-map
Cheers Norman
-
Antti Kantee -
Christian Helmuth -
Josef Söntgen -
Martin Unzner -
Nobody III -
Norman Feske -
Peter Lindener -
Tim Newsham -
Wolfgang Schmidt