users

users@lists.genode.org

6 participants
2306 discussions

Sculpt: fail to build stdcxx port
by Boris Mulder 29 Jan '18

29 Jan '18

Hi all, I wanted to try out the sculpt scenario from https://github.com/nfeske/genode.git. However, when I create the depot archive for stdcxx with > tool/depot/create genodelabs/bin/x86_64/stdcxx CROSS_DEV_PREFIX=/usr/local/genode-gcc/bin/genode-x86- I get the following error: > Library stdcxx-c++98 > MERGE stdcxx-c++98.lib.a >/usr/local/genode-gcc/bin/genode-x86-ar: basic_file_stdio.o: No such file or directory I already tried deleting the contrib directory and running prepare_port again, as well as starting from a clean directory. Furthermore, it is just a clean checkout of the repo. Googling the error message did not give me any useful results. Any ideas what I should do? -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)

2 1

Time For "Community Development" ML?
by John J. Karcher 26 Jan '18

26 Jan '18

Hi Norman, What do you think of setting up a new "Community Development" mailing list, for discussion and coordination within the development community that doesn't need the attention of the core developers? We're probably already at the stage now where it would be helpful, but I think the "Year Of Sculpt" will generate much wider hobbyist interest than in the past, which could disrupt the S/N ratio of this list. (Eventually, an end-user oriented ML would probably be a good idea also, but that should be a year or more away.) Thanks! -- John J. Karcher devuser@...544...

2 2

Linux IO_MEM session
by Johannes Kliemann 26 Jan '18

26 Jan '18

Hi all, I'm currently implementing a IO_MEM session for base-linux. The basic idea is as follows: - core opens a file in /dev/ and calls an ioctl on the file to set a memory range. - it passes this file descriptor to the child process that requested the session - the child process mmaps the requested memory range from the file descriptor The required device on Linux is already available (if you're interested, I've written a kernel module to provide it in [1]) so that isn't the problem. I tried to implement the IO_MEM session on base-linux but lack the understanding of how the Linux_dataspace and the Io_mem_dataspace are different. On base the Io_mem_session_component gets the dataspace capability from > _ds_cap = static_cap_cast<Io_mem_dataspace>(_ds_ep->manage(&_ds)); This doesn't work with base-linux since I can't cast the Linux_dataspace to Io_mem_dataspace. Yet I don't understand what I need to do this. I also didn't find out what parts of the session are executed in which context (speaking what runs in core and what in the component itself), especially where I would put the actual mmap call. My current implementation of the IO_MEM session is at [2] and [3]. Regards, Johannes [1]: https://github.com/jklmnn/hwiodev [2]: https://github.com/jklmnn/genode/blob/0cfcec98ad4d4fdfc7bf6cc6e6df3567360b4… [3]: https://github.com/jklmnn/genode/blob/0cfcec98ad4d4fdfc7bf6cc6e6df3567360b4…

3 8

noux_bash failure
by genode user 25 Jan '18

25 Jan '18

I have tried to build the noux_bash run file using the sel4 , nova and linux kernel options and so far have not had any success. Nova and sel4 both fail with: [init -> drivers -> acpi_drv] Error: ROM-session creation failed (ram_quota=6144, cap_quota=3, label="platform_info") [init -> drivers -> acpi_drv] Error: Could not open ROM session for "platform_info" Warning: no io_mem support on Linux (args="base=0xe0000, size=0x20000, wc=no, diag=0, label="init -> drivers -> acpi_drv -> ", ram_quota=3827, cap_quota=2") [init -> drivers -> acpi_drv] Segmentation fault (signum=11), see Linux kernel log for details This looked similar to a problem I found here: https://sourceforge.net/p/genode/mailman/message/35973788/ but changing the amount of ram in the suggested file did not help. I also tried changing the amount of ram specified for noux in the run file with no change in behavior. With the linux kernel I was told I am missing the genodelabs/pkg/drivers_interactive-linux archive but installing it fails with: /home/omavuto/projects/genode-17.11/genode-17.11/depot/ genodelabs/api/base-linux-2017-11-24/src/lib/syscall/linux_syscalls.h:383:27: error: ‘__sigword’ was not declared in this scope _value[__sigword(signum)] = __sigmask(signum); It may be that this is related to another problem I found. Earlier in the process I was told to install the base-linux archive with this command: /home/omavuto/projects/genode-17.11/genode-17.11/tool/depot/download genodelabs/bin/x86_64/base-linux but I get the error: Error: failed to download 'https://depot.genode.org/ genodelabs/src/base-linux.tgz' it looks like that this archive does not exist. I found a similarly named archive called base-linux-2017-11-27 which I was able to download. I then simlinked the base-linux-2017-11-27 to baselinux in depot/genodelabs/src/. That seemed to satisfy the requirement but perhaps the archive I used is somehow incompatible. Any suggestions on getting this to start? I am most interested in sel4 but suggestions for nova and linux are appreciated as well. Thanks!

2 3

Installing Genode within container
by Subhadeep Sarkar 24 Jan '18

24 Jan '18

Hi, I am a researcher at Inria France and am presently exploring Genode as a potential option to perform hands on with Sel4. I am relatively new to Genode and having an issue while installing it. Here is the issue: I am trying to install Genode on Ubuntu (16.04 LTS) running within a container . I am able to successfully see through all the installation steps. However, when I issue the final command: make -C build/x86_32 KERNEL=okl4 run/demo , I get this following error. make[1]: Leaving directory '/Genode/genode/build/x86_32' genode build completed using 'core-okl4.o' as 'core.o' using 'ld-okl4.lib.so' as 'ld.lib.so' using 'pit_timer_drv' as 'timer' install bootloader creating ISO image... xorriso 1.4.2 : RockRidge filesystem manipulator, libburnia project. spawn qemu-system-i386 -no-kvm -display sdl -serial mon:stdio -m 512 -cdrom var/run/demo.iso Could not initialize SDL(No available video device) - exiting Aborting, received EOF Log step failed, retry. spawn qemu-system-i386 -no-kvm -display sdl -serial mon:stdio -m 512 -cdrom var/run/demo.iso -cdrom var/run/demo.iso qemu-system-i386: -cdrom var/run/demo.iso: drive with bus=1, unit=0 (index=2) exists Aborting, received EOF Log step failed, retry. spawn qemu-system-i386 -no-kvm -display sdl -serial mon:stdio -m 512 -cdrom var/run/demo.iso -cdrom var/run/demo.iso -cdrom var/run/demo.iso qemu-system-i386: -cdrom var/run/demo.iso: drive with bus=1, unit=0 (index=2) exists Aborting, received EOF Log step failed, retry. I did install libsdl1.2-dbg . Clearly, I do not have a display connected, as I am trying to run it from within a container. Could you please help me with this issue? Thank you in advance! Yours sincerely, Subhadeep ------------------------------------------------------------------------------------------- Subhadeep Sarkar, PhD Postdoctoral researcher, Univ Rennes, Inria, CNRS, IRISA Inria Rennes - Bretagne Atlantique Campus universitaire de Beaulieu 35042 Rennes cedex, France Website: subhadeep.cf E-mail: subhadeep.sarkar@...552... ; subhadeepsarkarybs@...54... Phone: +33 2 99 84 73 52

4 10

Problem with running sel4 on Genode
by Subhadeep Sarkar 23 Jan '18

23 Jan '18

Hi, I am facing some trouble while launching Sel4 on top of Genode. I am trying to do it by the document at https://genode.org/documentation/articles/sel4_part_1 . When I run the command: sudo ./tool/ports/prepare_port sel4, I get the following error, which I am unable to bypass. subhadeep@...554...:~/Git/genode$ sudo ./tool/ports/prepare_port sel4 sel4 update src/kernel/sel4 sel4 apply /home/subhadeep/Git/genode/repos/base-sel4/patches/arm_cache.patch 1 out of 1 hunk FAILED -- saving rejects to file src/kernel/sel4/libsel4/arch_include/arm/sel4/arch/types.h.rej /home/subhadeep/Git/genode/tool/ports/mk/install.mk:129: recipe for target 'phony/patches//home/subhadeep/Git/genode/repos/base-sel4/patches/arm_cache.patch' failed make[2]: *** [phony/patches//home/subhadeep/Git/genode/repos/base-sel4/patches/arm_cache.patch] Error 1 /home/subhadeep/Git/genode/tool/ports/mk/prepare_single_port.mk:38: recipe for target '_install_in_port_dir' failed make[1]: *** [_install_in_port_dir] Error 2 tool/ports/prepare_port:33: recipe for target 'sel4' failed make: *** [sel4] Error 2 I would really appreciated any help with this, as I am unable to decode the error. Thank you for your help! Yours sincerely, Subhadeep ------------------------------------------------------------------------------------------- Subhadeep Sarkar, PhD Postdoctoral researcher, Univ Rennes, Inria, CNRS, IRISA Inria Rennes - Bretagne Atlantique Campus universitaire de Beaulieu 35042 Rennes cedex, France Website: subhadeep.cf E-mail: subhadeep.sarkar@...552... ; subhadeepsarkarybs@...54... Phone: +33 2 99 84 73 52

2 3

Re: Roadmap 2018
by unknown＠example.com 23 Jan '18

23 Jan '18

2 1

Genode region mapper
by Valery V. Sedletski 21 Jan '18

21 Jan '18

Hi, I'm now trying to port my L4Env-based program to Genode. It is a runtime environment to run OS/2 programs on a L4 family microkernel (Inspired by OS/2 Warp, PowerPC edition/IBM Workplace OS). Currently, the working version (actually, some proof-of-concept) is running under L4Env, but I plan to port it to Genode and L4Re (and maybe, to WinNT native/ReactOS in the future). For porting purposes, I need to have some region-mapper functionality, like 1) reserve a virtual memory region in the region map, so that it will avoid attaching dataspaces over this region, unless an explicit attachment address is specified; 2) lookup an address in the region mapper, i.e., determine, is this address free, reserved, or some dataspace is attached here, and if so, at which address/offset and which size. For implementing the memory management functions, this is needed to reserve a virtual memory block, for subsequent committing pages/attaching dataspaces in that region, step by step. As I looked at the Genode::Region_map interface, I don't see such functions in that class. Though, I found some memory-range allocation routines in the Genode::Range_allocator class, but I'm not sure if this is what I need. Is there some functionality related to reserving regions/looking up addresses implemented elsewhere, or I need to implement such functionality myself? Also, a required feature is multiple memory areas support in the region mapper. I need at least, two memory areas, a private one, and a shared one. A private area start at the beginning of the address space. It is private to any user-mode program. A shared area starts at some higher address, and it is common for all usermode programs (using my runtime environment). So, it is a global shared memory started at the same address, and each shared memory region is mapped at the same address in all client address spaces. It is used for shared memory IPC,Â as well as for loading DLL's. DLL's are shared between different usermode programs, unlike Windows DLL's or Unix SO's. So, I need to allocate memory ranges in specific (private or shared) areas. This could be implemented via my own memory manager with its own accounting. But maybe, there is an already implemented functionality, like this? L4Env region mapper has support for multiple memory areas, as well as a possibility to lookup an address, or to attach a pointer to a user-defined structure, to an address. So, I can attach my own data related to that address/region. Is there a functionality like this implemented in Genode? I also know, that there is a support for managed dataspaces, or nested region maps, which could be useful here (at least, for implementing a shared memory area), but I also know, that nested region maps are not supported on all platforms (like Genode/Linux). So, it would be, possibly, better to avoid using them, unless really needed. WBR, valery

2 6

Roadmap 2018
by Norman Feske 21 Jan '18

21 Jan '18

Hello everyone, like every year in December, I'd like to kick off the discussion of Genode's road map for the upcoming twelve months. It goes without saying that your feedback and suggestions are very welcome. Should you have any plans related to Genode, please do not hesitate to chime in! Before I present my rough plans, let me take a minute to review the past year. Review of 2017 -------------- As Johannes Schlatow's team put it so nicely in their Christmas card (thanks a lot!), the "Turmvilla" era lies behind us. So let the "Sculpt" era begin! Whereas Turmvilla allowed me to work on a Genode-based system since mid of 2015, the scenario was quite rigid and required significant manual labour for any customization. Although it was not really inviting for potential users, it illustrated well that all the basic building blocks - in particular the driver stacks - were in place. But it would have been be quite a stretch to call Turmvilla a general-purpose OS at that point. The new Sculpt scenario that I started to put together this autumn leverages two key features of 2017 to ultimately enter the realms of general-purpose computing. Those features are the dynamic init and the package management. The combination of Genode's recursive architecture with the dynamic reconfigurability of the init component allows me to interactive shape the running Genode system including any subsystem or even configurations of individual components. The system structure is at my fingertips and I can change it instantly using my favorite text editor. This excites me to no end! :-) At the same time, the new package management greatly helps to keep the complexity at a manageable level. Whereas I rarely updated my Turmvilla installation out of hesitance to break my work environment, I routinely update Sculpt on a weekly basis. Not only do I but also all my team mates at Genode Labs! The switch of the entire Genode-Labs team to Genode full time was certainly our biggest milestone of the year. At the technical level, the use of the gained cross-kernel binary compatibility or the VFS infrastructure have already become a second nature. Regarding the latter, remodelling this infrastructure to an asynchronous mode of operation was certainly a long and stony way. I am extremely grateful to Emery and Christian for having taken a big share of this labor-intensive work! Now, we can start to reap the fruits of this development. How to proceed in 2018? ----------------------- Personally, I'm to eager to take Genode in two main directions. First, the Sculpt scenario will for sure spawn manifold developments to the benefit of end users. Those developments will include documentation to make Sculpt palatable to users, the further cultivation of Genode's package-management concept, the composition of new subsystems, and the optimization of daily work flows. The progress in this direction will be quite organic and primarily motivated to make our daily computing experience more effective and fun. The second direction is the application of Genode for real-time graphics and sound processing - in a way reigniting my past passion of programming demo effects on the Atari Falcon. ;-) The path for this activity was paved this year by Josef and Sebastian who created our driver infrastructure for Intel GPUs. By actively using this infrastructure along with the audio stack, I am eager to push Genode towards low-latency multimedia performance. In order to do that, I will have to improve the tools for gathering runtime data (e.g., putting our tracing infrastructure to good use), gain a profound understanding of the behavior of complex scenarios, and optimize. Aside these playful activities, I also want to focus on the quality and resilience of our software. The modernized framework API introduced last year is an important stepping stone. But there is much more we can (and should) do, I.e., learning from the high-integrity computing community (e.g., implementing critical components in SPARK), leveling-up the scope and intensity of our automated tests, facilitating static code analysis, and employing software-hardening techniques. Of course, this scope goes far beyond the time frame of one year. The immediate priorization of these topics will largely depend on the focus of commerical users funding the work. The aspirations outlined above are my personal perspective. Please do not hesitate to share yours! Any comments and suggestions are appreciated. Maybe you even have tangible or less tangible Genode-related plans as well? I would be happy to learn about them! The outcome of the discussion will eventually become the official road map for 2018, which I am going to announce in mid of January. Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com Â· https://genode.org Genode Labs GmbH Â· Amtsgericht Dresden Â· HRB 28424 Â· Sitz Dresden GeschÃ¤ftsfÃ¼hrer: Dr.-Ing. Norman Feske, Christian Helmuth

8 21

FOSDEM 2018
by Norman Feske 16 Jan '18

16 Jan '18

Hello everyone, just in case you are not monitoring the news items at genode.org, let me make you aware of the upcoming FOSDEM (https://fosdem.org/2018/) held on 3rd and 4th of February. The microkernel developer room at FOSDEM is the melting pot of the open-source microkernel world where projects and users meet to present their work and experience with microkernel-based operating systems. Like every year, we will take the chance to present the recent achievements of Genode to the audience. There will be three presentations from our team, covering our recent work on hardware-accelerated graphics, user-level networking, and the dynamic sculpting of a Genode-based system. If you are curious about the topics, or interested in meeting the people behind the various projects, please do not hesitate to join us! The microkernel developer room will take place on Saturday in room AW1.126. The schedule for the Genode-related talks is as follows: 11:05 GPU resource multiplexing in component-based systems by Sebastian Sumpf 12:25 Live sculpting a Genode-based operating system by Norman Feske 17:30 User-level networking on Genode by Martin Stein For the complete schedule along with abstracts for the talks, please refer to: https://fosdem.org/2018/schedule/track/microkernels/ Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com Â· https://genode.org Genode Labs GmbH Â· Amtsgericht Dresden Â· HRB 28424 Â· Sitz Dresden GeschÃ¤ftsfÃ¼hrer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users