users

users@lists.genode.org

3 participants
2349 discussions

Roadmap 2017
by Dr. Florian Manfred Grätz 17 Jan '17

17 Jan '17

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.

3 2

Loading of software modules at runtime vs. loading at boot time.
by Dr. Florian Manfred Grätz 16 Jan '17

16 Jan '17

Dear Genode community, I am gradually digging into the details of the Genode framework and was thinking about compiling a Live-CD. My intension is to give unexperienced users a first impression of Genode by simply downloading an .iso image and either booting it into their real machine using a thumb drive or using an emulater like qemu/virtualbox. Please refer to my last post for the rationale behind it. The good news is, that genode-world seems already to provide a set of software packages, which have been ported. However, I am currently under the impression, that genode currently is not capable of loading software modules at runtime. Instead, it appears to me, that all required software modules are linked into a large elf file, which is then loaded during boot time. Am I missing something crudential here or is loading of modules at runtime not yet implemented? Regards, Florian.

2 1

report_rom clarification about the validity of ROMs in case the report session was closed
by Johannes Schlatow 16 Jan '17

16 Jan '17

Hi, I (more precisely: a student of mine) noticed that a ROM provided by the report_rom is cleared once the corresponding Report session is closed. I looked at the implementation, which intentionally clears the dataspace when the writer (i.e. the report session) is unregistered from the Rom_module. I'm curious about the reason for this. More specifically, I am wondering why the report_rom does not invalidate and notify the registered ROM sessions after the content was cleared. Currently, the ROM clients will just see that the content disappeared without getting any signal, which seems a bit counterintuitive/inconsistent to me. Cheers Johannes

2 4

Unified build directories / adaptation to the new API
by Norman Feske 13 Jan '17

13 Jan '17

Hello everyone, I am happy to report that we wrapped up the first phase of our big API adaptation work today and introduced the unified build directories into the master branch. This posting is both a heads-up warning and an invitation to experiment with the new mechanism. First, the warning part (quite literally): With the commit "Warn about the use of deprecated env() function" [1], a compiler warning will appear each time the legacy 'env()' function is used, either explicitly or implicitly. This makes it easy to spot the places that need our attention because they still rely on global side effects. Since New Year, we have been very busy to overhaul our code base and made huge progress. Thanks to everyone involved! However, as you will see, there are still many places left unattended. Therefore, the warnings somehow spoil the impression when building Genode right now. Their main downside is that build errors and important warnings are more difficult to spot. Please bear with us. ;-) Don't worry though, the "deprecated" warnings are merely cosmetic and will gradually disappear. [1] https://github.com/genodelabs/genode/commit/a7f40b24cad0a34f0ac0bd9256a5285… Second, I proudly present you the fruit of my labor with respect to the Genode ABI. Genode has now become able to use different kernels from within the same build directory. Of course, this change comes with a sight change of the tooling, in particular to the 'create_builddir' tool, the build system, and the autopilot tool. Let's take the new version for a quick test drive. 1. Checkout the current master branch of Genode. git clone https://github.com/genodelabs/genode.git 2. Invoke the 'create_builddir' tool to see the new options of build directories. cd genode ./tool/create_builddir As you can see, the original kernel-specific platform parameters are still there but they are marked as "deprecated". They will be removed shortly. The new unified build directories are the new way to go now. There is one option for each supported hardware platform, e.g., 'x86_64', or 'usb_armory'. Note that the kernel is left unspecified. Assuming you have a 64-bit Linux host system, let us create a build directory that matches your Linux system: ./tool/create_builddir x86_64 (if you are using a 32-bit Linux system, specify 'x86_32' instead) Now, enter the build directory and look at the build configuration: cd build/x86_64 <editor> etc/build.conf You may notice the changed "Run-tool configuration" section. Parts this configuration are dependent of a new 'KERNEL' variable. The variable has the following effects: * It selects kernel-specific run-tool arguments 'KERNEL_RUN_OPT', * It selects kernel-specific Qemu arguments, e.g. 'QEMU_OPT(nova)' * It adds the kernel-specific 'base-<kernel>' directory to the list of source-code 'REPOSITORIES'. Once you have your build.conf open in your editor, you may enable parallel build by uncommenting the corresponding line at the beginning of the file. 3. Let's build a Genode component, e.g., init: make init Wow, that was quick! The build system created the init binary without even building any parts of the Genode base system. How is that possible? The answer lies at 'repos/base/lib/symbols/ld', which is the binary interface provided by Genode's dynamic linker. The build system uses this information to build a pseudo shared object that is linked against init instead of the real dynamic linker. From the perspective of the init executable (just put yourself into the shoes of an ELF executable to follow me), it feels like being linked against Genode's dynamic linker that provides the base framework. But in reality, you got presented just an empty hull of Genode - a bunch of symbols. In case you are curious, you can find this ABI stub library at var/libcache/ld/ld.abi.so. If you look closely into the build subdirectory of init/, you will see that the used 'ld.lib.so' is actually a symlink to the stub. At this point, the build directory is clear from any kernel- specific peculiarities. 4. Building a kernel To build a kernel, the build system needs to know the kernel- specific parts of Genode, i.e., the corresponding 'base-<kernel>' source code repository must be added to the 'REPOSITORIES'. The default build configuration does this automatically if you specify a 'KERNEL' argument: make kernel KERNEL=nova At this point, the build system may point out that you will need to download the kernel source code. Just follow the proposed command to do these preparatory steps. If done, execute the above command again. In the particular case of NOVA, the result of the kernel build can be found at 'kernel/nova/'. 5. Executing a scenario on Linux Let's build and execute Genode's graphical demo scenario on your Linux host system: make run/demo KERNEL=linux The build will take a while. Most of the produced components are kernel-independent. Only a few, such as core, fb_sdl, and the timer driver are Linux-specific. Also a Linux-specific version of Genode's dynamic linker will be built. It is named 'ld-linux.lib.so'. Once the build completes, the scenario is executed. So you should see a window with the demo scenario popping up. 6. Switching to another kernel Now, let's execute the same scenario on, let's say, NOVA. To use this kernel instead of Linux, a few actual drivers are needed. So let us enable the 'libports' and 'dde_linux' repositories in the build configuration. At this point, you may have guessed the command to use: make run/demo KERNEL=nova You will be prompted to prepare a few ports of 3rd-party software, in particular, the libc, dde_linux (USB driver), x86emu (for VESA). After installing those ports, issue the above command again. Note that the build process will build the additional drivers and NOVA-specific parts of Genode. But all the components that we built before when executing the scenario on Linux remain untouched now. At the end of the build process, the scenario is stared in Qemu. To sum it up, switching from one kernel to another has become just a matter of the 'KERNEL' argument. This has a number of benefits: * When using multiple kernels, there is no need to have multiple build directories. You waited an hour to build a Qt5-based scenario on NOVA but want to run it on Linux now? This is now possible in a few seconds. * If an executable has a bug, the bug will be there regardless of the kernel being used. To debug the problem, you can use the kernel with the most appropriate debugging instruments available. * The packaging of kernel-agnostic binary packages has become within close reach now. * The new ABI feature that works so well for Genode's dynamic linker can actually be leveraged by arbitrary libraries. For example, I just introduced an ABI for the libc (libports/lib/symbols/libc). So in the future we can even have multiple levels of ABI stability. I hope that you will like the unified build directories. This being a very recent development, there may still be rough edges. Your feedback is very welcome. I hope that we will have smoothened those edges and removed most of the "deprecated" warnings by the time of releasing version 17.02 at the end of February. 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

2 1

Roadmap 2017
by Norman Feske 09 Jan '17

09 Jan '17

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. Just to name a few topic: * 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 -- 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

12 25

removing L4Linux
by Stefan Kalkowski 03 Jan '17

03 Jan '17

Hi folks, since the very first project that used L4Linux on top of Genode, almost nobody cared much about it. The main developers of Genode do not make use of it, and I do not know of any project currently depending on it. When it comes to OS ABI compatibility, we make use of VMMs like VirtualBox or Seoul. For device driver support, the project also do not follow the L4Linux approach, but drivers are built by ourselves or we port them using the device-driver environment (DDE) approach. On the other hand, L4Linux often stands in the way when e.g., modernizing the Genode API like with recent issue #1987. It also kept me from upgrading to newer Fiasco.OC kernel versions in the past, because of the dependencies of L4Linux with regard to the kernel. In contrast to L4Linux, I know that people are using Genode with Fiasco.OC and would profit from newer versions. I also do so, e.g., when using Fiasco.OC's debugger on real hardware. If maintaining Genode/Fiasco.OC gets easier by removing the burden of L4Linux I'm for it. Nevertheless, if somebody is still actively using it, we should find a solution, e.g., by sharing the maintenance effort, or moving the current state into the Genode world repository. I have opened an issue accordingly: https://github.com/genodelabs/genode/issues/2216 If you have a future interest in L4Linux on top of Genode, please contribute to the discussion in the issue tracker. Best regards Stefan -- Stefan Kalkowski Genode Labs https://github.com/skalk · http://genode.org/

2 1

Could Genode use page table ideas from Akaros, RiscV ?
by Peter Lindener 01 Jan '17

01 Jan '17

Dear Fellow Genodians- I was reading through some blog notes from the latest RiscV workshop <http://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-one/> when I came across some suggestions relating to page table managment <https://riscv.org/wp-content/uploads/2016/12/Wed1130-RISC-V-VM-threads-Minn…> contributed by folks on Berkeley's Akaros project <http://akaros.cs.berkeley.edu/akaros-web/news.php>.. a ways back, I recall a discussion relating redundant structure in the Genode OS... and wounder if the Akaro's projects thinking might also be of some use with Genode's support for VMs... While I lack the perspective needed to appreciate the pro's and con's of this approach...and for that matter understand that Genode is more about a recursive OS API, than the page table map that might be found underneath.. It might be good for the Genode Team to chime in with Akaros as might relate to MMU systems for the RiscV project.. Anyone close to the iron care to chime in on this? -Peter

1 0

USB storage detachment / reattachment
by Martijn Verschoor 23 Dec '16

23 Dec '16

Dear Genode community, Currently I’m working on a scenario that includes loading a file from USB storage device (stick). I have a composition that works in principle but has ‘rough’ edges, particularly regarding detachment / reattachment of the USB storage device. I’d like to share my approach with you and appreciate your feedback / suggestions on what I could improve. A rough sketch of the scenario is: A user: - inserts a USB storage device with candidate files in an available USB port on the platform - x86 in this instance, - selects one or more files on the USB storage device to load - using a custom CLI, - removes the USB storage device. - (and sometime later) repeat the steps above. A short description of the composition (top-down): - the custom CLI component requests a file session with a rump_fs server when handling a user command. - the rump_fs server has a block session with a part_blk server. - the part_blk server has a block session with the usb driver (dde_linux/x86), using storage. I attached a run script snippet that shows these relations. The USB storage device is formatted with ext2fs. My (initial) findings: - When I insert the USB stick, the usb driver detects the mass storage device and consequently the rump_fs server mounts the ext2fs. The CLI component can access the filesystem and list/read/write files on the USB stick. All as expected. - When I remove the USB stick, the usb driver detects removal, but the rump_fs remains unaware. The CLI component can successfully open new file system sessions and even list the files in the root directory, even though the actual storage device is detached... - The rump_fs server aborts when a filesystem is not of the expected type. - To complicate matters more, the target platform is booted from a - different - USB stick. Currently the usb driver detects this USB stick as mass storage device and the rump_fs aborts because the fs is not the expected ext2fs. For the latter finding, I am aware that the usb driver supports a policy mechanism for raw devices (in combination with the usb_report_filter component). But to my knowledge for storage devices, such a policy mechanism does not exist, right? Regarding detachment / reattachment of USB storage, I understand that at startup of this composition, the rump_fs server immediately requests a block session at the part_blk server, which in turn requests a block session at the usb driver. This whole blocks until a USB storage device is plugged in. When this happens, the chain of sessions requests is setup and the file system client can access the medium. Now if the USB storage device is detached, what happens to the open sessions? As a way to support detachment / reattachment of USB storage I’m thinking about placing the rump_fs and part_blk components in a child subtree of the CLI component that is spawned on demand and cleaned-up after use. But this seems a bit like overkill. Am I overlooking the simple solution? Met vriendelijke groet / kind regards, Martijn Verschoor Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office) | +31 616 014 087 (mobile)

3 3

FWD: List of accepted talks for Microkernel/Component OS devroom @ FOSDEM 2017
by Josef Söntgen 22 Dec '16

22 Dec '16

Hi everybody, the schedule for the FOSDEM 2017 microkernel devroom is finished and the Genode community participates in devroom as it did in the past. There are some Genode related talks and a handful of Genode developers will attend the conference. So if you want to meet up, the FOSDEM is the ideal place. Regards Josef ----- Forwarded message from microkernel-devroom@...86... ----- Hello everybody, I am glad to annouce that we mananged to accept all submitted talks: A kernel in a library — Genode's custom kernel approach Martin Stein Deterministic replay support for Genode components: Performance penalty and challenges Mahoukpego Parfait Tokponnon Introducing kernel-agnostic Genode executables Norman Feske HelenOS in the year of the fire monkey Jakub Jermář Redox OS — A safety-first microkernel developed in Rust David Teller Secure Microkernel for Deeply Embedded Devices Jim Huang TCP/IP for MINIX, the good, the bad, the ugly Philip Homburg The VFS paradigm from the perspective of a component OS Christian Helmuth Virtualization on the Hurd Justus Winter The schedule can be found the FOSDEM website [1]. [1] https://fosdem.org/2017/schedule/track/microkernels_and_component_based_os/ On a side note I would like to ask every speaker to join this mailing list to have one common communication channel for discussing any further matters regarding the devroom's organization. Best regards & see you at FOSDEM! ----- End forwarded message ----- -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/

1 0

Re: Updating Genode's license to AGPLv3 + open-source linking clause
by Nobody III 19 Dec '16

19 Dec '16

I'm thinking of the possibility of Genode becoming a consumer OS platform. One benefit of Genode is that a user doesn't need to trust every single program running on his computer. If I have to run a piece of proprietary software, Genode would be my preferred platform. Also, for software that I don't have to trust, I don't care as much whether it's proprietary. I would prefer that Adobe and Autodesk port their software to Genode, especially since 3D software doesn't work well in VirtualBox. I prefer free software because it's more trustworthy, but I still use some proprietary software (e.g. Google Chrome with Flash Player). On Dec 17, 2016 8:38 AM, "Norman Feske" <norman.feske@...1...> wrote: Hello Ben, > Am I correct that software that doesn't link directly to any AGPLv3 code > (e.g. code that just uses libc) is okay to have proprietary licenses? this is not correct because the proprietary code would still linked to Genode in addition to the libc. > That seems to be the logical interpretation, and probably the most > beneficial, as it wouldn't discourage companies from porting their > software to Genode. This statement is interesting because it raises the question of the motives and goals behind Genode. What does "most beneficial" mean? Beneficial to whom? Let me try to look at this question from different perspectives. 1. The Free Software user For an end user who consciously uses a Free Software ecosystem, proprietary applications are not interesting because they restrict the freedom of the user. Frankly speaking, I am an example of such a user. I have not touched proprietary applications on my computer since several years. But I vividly remember the inconvenience of using opaque installers, the lack of security updates, the inability to fix bugs, or the suspicion about backdoors and vulnerabilities introduced by such applications. The argument that an operating system would be useless without proprietary applications was probably valid 15 years ago. Today, the Free Software world is so strong and diverse that this argument does not hold anymore. 2. The consumer Many end users are neither aware nor interested in technical details. They just want to get work done, browse the web, play games, or watch movies. From the operating-system's perspective, I also see professionals (like photographers, writers, business users) in this category. A typical consumer uses the OS that comes pre-installed on the device, and accepts the inherent dependency from commercial vendors. The user does not care too much about the uppercase Freedom of software. I am sometimes such a user. E.g., when using my portable audio player, I just want to listen to music. 3. The proprietary application vendor For a proprietary application vendor, the consumer (2) is a business case. The application vendor wants to create and distribute applications with as little costs as possible and sell them to the consumer at the highest price possible. The latter would not be easily possible if the application vendor published its own "intellectual property" to everyone for free. Hence, the applications tend to stay proprietary to uphold the business case. The application vendor has to consider expenses like paid-for development tools, licenses of commercial libraries, or app-store fees as cost factors. It is clear that proprietary application vendors welcome liberally licensed open-source libraries or platforms for hosting and distributing proprietary software at no costs. 4. The proprietary platform vendor A vendor may use Genode as the basis of a proprietary platform, for example an appliance designated for a specific market. But such a platform may in principle also be targeted at the consumer mass market. In order to use Genode as the basis of a proprietary platform, the platform vendor obtains a commercial license of Genode. In this case, the choice of Genode's regular open-source license is not a concern for such a platform vendor. 5. The Free Software developer The motives of Free-Software developers are diverse. But regardless of the motives, they generally improve the lives of Free-Software users. If the software addresses consumer needs, Free-Software developers often find themselves as competing with proprietary applications. Of course, the categories are not clear-cut. But they help to address two questions: (1) Who would benefit from the ability to host proprietary applications on top of the open-source Genode system, and (2) whom do we want to cater with the open-source license of Genode? Regarding question (1), only the proprietary application vendor would immediately benefit, but only under the condition that Genode is a platform used by their target audience (consumers). This is of course not the case. Hence, for an application vendor, there is no business case for porting their applications to Genode at all. Instead, application vendors focus on popular end-user platforms like iOS, Android, Windows. Regarding question (2), with Genode's open-source license, we want to cater Free-Software users and Free-Software developers in the first place. Acknowledging that the open-source Genode system is not a consumer platform as is, there is no benefit in catering the interests of proprietary application vendors with Genode's open-source license. Please don't get me wrong. I don't dismiss consumers. I see two principle ways of how Genode can reach popularity among consumers, by becoming a consumer platform, or by consumers gravitating towards Free Software. Regarding the former, I am convinced that Genode can become a popular consumer platform only with strong commercial incentives of a platform vendor. Should a platform vendor develop such an interest, it would seek a commercial license. The funding obtained from the commercial licensing would ultimately help Genode and thereby the Free-Software community. The second direction is that consumers would buy products that are solely based on Free Software. Personally, as a Free-Software user, I find this prospect quite exciting. Given this line of thinking, I hope that you agree that the ability to host proprietary applications on top of the open-source Genode system would not bring any tangible value. But maybe I have overlooked something? Please don't hesitate to share your thoughts. Regards 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 ------------------------------------------------------------ ------------------ 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 genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

5 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users