users

users@lists.genode.org

2285 discussions

mmap implementation for ANON mapping with desired address
by Alexander Tormasov 21 Dec '20

21 Dec '20

I am trying to implement not-yet supported (as mentioned by nfeske@ in mailing list) option for mmap() related to anonymous mapping with pre-defined (desired) address. Like libc function with desired address out_addr. void *Libc::Mem_alloc_impl::alloc_at(void *out_addr, size_t size) I use a couple of useful function in avl allocator. Anyway, I found that straight - forward implementation do not work because of allocation gaps filled together with main allocation. In particular, if we want to allocate e.g. 0x10000 from address 0x500000 then we typically allocate 0x13000 bytes, including ones for avl metadata/etc stored in the same space, and receive virtual address range used, e.g. 0x500000 - 0x513000: /* * Calculate block size of needed backing store. The block must hold the * requested 'size' with the requested alignment, a new Dataspace structure * and space for AVL-node slab blocks if the allocation above failed. * Finally, we align the size to a 4K page. */ size_t request_size = size + max((1 << align_log2), 1024) + Allocator_avl::slab_block_size() + sizeof(Dataspace); Software I used (golang runtime) sometimes try to expand previous allocation, e.g. it can request allocation of 0x8000 bytes before previous range, like 0x4f8000 - 0x500000. In that case I can’t perform the operation - because it will try to allocate 0xa000 bytes from desired address 0x4f8000 - and it obviously fail due to Range_conflict. So, I split allocation to 2 parts - one for this gap by standard alloc() and random placement and second one by my own alloc_at() with size exactly correspond to the requested one. Implementation available as a patch to 20.05 at https://github.com/tor-m6/genode/commit/78fc751bea8acc2b515e04bec9f3a883461… Problem I see here is a free operation: it just free the block with requested address, and do not touch others, gap-related blocks. For me it is not obvious that they need to be free, because in the code (e.g. by unmap()) I do not see explicit free of other allocated structures, in particular, dataspace extension or related block metadata. Question: should I make additional efforts to trace and delete something else - except what standard free does here: /* forward request to our local allocator */ _alloc.free(addr); Like for dataspace structure or address ranges for second «auxiliary» allocation? PS Another potential problem is a probability to overlap of first «random address» allocation with desired address. This happens with first attempt to implement allocator - it allocates address from desired range, and immediately put here 0x18 bytes of Dataspace structure, and then fail because requested address is already busy by this structure! Anyway, I consider such a probability relatively small with proposed approach and ignore it (may be I am wrong)

4 23

My roadmap
by Michael Grunditz 19 Dec '20

19 Dec '20

Hi everyone, I was reading the 2020 reflections on Genode. Here is my plans for 2021 related to Genode: 1) Make the RK3399 port complete which for example includes PineBook Pro. HDMI will be easy, and I think eDP will be as well. The question is if doing it with DDE-Linux or from scratch. The RK3399 port is really only a exercise for me , since we already is on our way with a native port of RISC OS. But I guess a port of Genode can be useful for others. 2) RISC OS kernel running on top of base-hw , big project: 2a) The RISC OS kernel is written in ARM assembler, I will attempt to bring it over to C. 2b) Replace HAL with Genode facilities. 2c) Write some kind of emulation layer. RISC OS uses SWI for everything and that will not work on 64bit. It will be important to be able to run 32bit programs. 2d) Bring up Genode on all future aarch64 systems! 3) Bring up Genode on A64... I guess it might have been done partly already. It is the SoC that PinePhone is built on. I have been in the team porting RISC OS to A64 , so I know a few things. The only thing we haven't done natively is graphics. The only doc for DE 2.0 is a register description (VERY large document). No appnotes which makes it close to impossible to do without looking at BSP. We used simplefb , that is , starting graphics in uboot and use the resulting framebuffer. NetBSD also does graphics this way. 4) Learn to use the DDE-Linux. I hope that 2021 will be healthier :) Best regards, Michael Grundiitz

2 1

update openssl port
by Duss Pirmin 17 Dec '20

17 Dec '20

Hi Genodians On December 08. 2020 the openssl project issued a security advisory (https://www.openssl.org/news/secadv/20201208.txt). I started looking into binging the latest version of openssl (1.1.1i) to Genode. I have a first version of the library that compiles on x86_64. When I started testing components I encountered the following things: - `wpa_supplicant` (wifi driver) compiles, but running it fails due to a symbol the dynamic linker can't find - `lighttpd` compiles, but running it fails due to a symbol the dynamic linker can't find - `libssh` doesn't compile (it looks, as it uses data structures that were moved to internal only in version 1.1.x of openssl) - `openvpn` (repo genode-world) doesn't compile (it looks, as it uses data structures that were moved to internal only in version 1.1.x of openssl) - `grpc` (repo genode-world) compiles with some warnings about using deprecated functions - `grpc_tls/client` and `grpc_tls/server` (repo genode-world) can be built I'm thinking about how to proceed with this. One way that I see, is to create a separate port (e.g. `openssl_1.1`) that provides the updated library. Then each component can choose to use the old or the new version of the library. When a component (or library) is updated, one can choose to switch to the new library if it is supported. In the long run the old version of openssl could then be removed once all users of it have switched. Do you agree with proceeding according to this plan or would you approach this differently? Best regards, Pirmin

4 3

vfs fifo pipe and file system session write
by Stefan Thöni 09 Dec '20

09 Dec '20

Hello Genodians We are still trying to introduce a named pipe for communication between libc components and pure genode components. Our vfs fifo pipe now works with multiple threads in the same process, but only when it's hosted in the vfs of that same component. As soon as we host it in separate vfs component it stalls randomly. Our analysis shows that the reason for this lies in the implementation of the file system session interface, where the write operation doesn't report back the number of bytes written but the receiving vfs component instead retries the write operation. This leads to a permanent blocking of the vfs component as no read operation can alleviate the full buffer of the fifo pipe. We think the only proper fix would be a change in the file system session to allow the write operation to report back the number of bytes written. Is there a specific reason to keep the write 'fire-and-forget', other than simplicity? Best regards Stefan -- Freundliche Grüsse Stefan Thöni Chairman of the Board Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 3

whether genode c++ support RTTI
by yadong.li 09 Dec '20

09 Dec '20

Hi， I am a newer， I have some question about genode about c++ RTTI My test command is “make -C build/x86_32 KERNEL=sel4 BOARD=pc run/demo”, my genode version is “19.02” I add “typeid”, compile warning “must inclue <typeinfo>”, but this must compile add “stdcxx” lib, If add stdcxx, they need “Libc::Component::construct”, it is conflict with “Component::construct” of genode How can I resolve it, or Is there some demo support c++RTTI ? Thank you very much

2 1

CfP: FOSDEM 2021 - Microkernel Devroom
by Martin Decky 07 Dec '20

07 Dec '20

Microkernel Devroom at FOSDEM 2021 CALL FOR PARTICIPATION On-line version of this CfP: http://fosdem.microkernel.info/ The developers and users of several free and open source microkernel-based operating systems will meet on-line as part of FOSDEM 2021 [1] and will share a developer room. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-based, unikernel-based, component-based operating systems and similar topics. The devroom has been preliminarily scheduled to Saturday February 6th 2021. The devroom will take place during European day hours. Possible topics of the devroom include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * used languages, tools and toolchains * enabling support for hardware (architectures, device drivers) * enabling support for programming languages * development processes, debugging * maintenance, testing and release engineering * security and robustness * trends and challenges * community and governance * use cases, experiences and status updates * best practices, lessons learned and demos This is a call for your participation. We kindly ask you to submit your proposals no later than on December 26th 2020. Please use the Pentabarf website [2] to submit your proposals. If you already have a user account in Pentabarf, please do not create a new one. Please make sure to select the Microkernel devroom as the track when submitting your talk and include at least the following information in your proposal: * title of your talk * your full name * short abstract of your talk (one or two paragraphs) * duration of your talk (at least 20 minutes and no longer than 50 minutes), excluding a Q&A part * your short bio * your photo The talks will be pre-recorded in advance in January and streamed during the event. This means that you will need to complete and submit your talk by around mid January. However, each speaker should be also present on-line just after the streaming of the talk for a live Q&A. You can specify your prefered time slot of your talk. The communication language of the devroom is English. The official devroom schedule (along with the accepted talks) will be announced on December 31st 2020 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM website. You are also invited to send any other suggestions for what you want to see or do at the devroom to the mailing list. About the Devroom Since the first Microkernel devroom at FOSDEM 2012 [4], this devroom has been part of each following FOSDEM. The focus gradually widened to include component-based and unikernel-based operating systems. By now it has become a somewhat institutionalized tradition for the community to meet there. To this date, over a dozen projects have participated in one way or another. Each of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Extraordinary Circumstances in 2021 Due to the extraordinary mode of organization of FOSDEM 2021 (being an on-line event for the first time), many practical aspects of the devroom are still in the process of determination. For example, the devroom talks will be required to be pre-recorded in January and streamed during the event (with a live Q&A), but the technical details are still sketchy at this moment. The talk videos will be published under Creative Commons license by FOSDEM. By submitting a recorded talk, the speaker agrees to have it made available publicly indefinitively. For organizational purposes, we also need contact information of the speakers of accepted talks. Please check the official CfP page [5] of our devroom regularly. We will keep updating it as new guidelines will be determined by the FOSDEM organizers. Sadly, it will not be possible to arrange our traditional microkernel dinner and other in-person social gatherings in Brussels this time. However, we plan to organize an on-line replacement. The details will be announced later in January. On the other hand, the on-line nature of the devroom allows us to "overflow" to a second day in case we receive a substatial number of quality proposals. About FOSDEM FOSDEM [6] is a two-day event organised by volunteers to promote the widespread use of free and open source software. FOSDEM is widely recognised as one of the best such conferences worldwide. FOSDEM covers a wide spectrum of free and open source software and hardware projects and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and proposals. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, and in the past instances certification exams and project stands. In recent years, FOSDEM has been hosting more than 5000 developers at the ULB Solbosch campus. Due to the circumstances, FOSDEM 2021 will be organized as an on-line event. Despite this, the participation in FOSDEM is still totally free, although the organisers gratefully accept donations and sponsorship. No registration is necessary, but attendees are expected to follow the FOSDEM's code of conduct [7]. Important Dates Recap * 2020-12-26: Deadline for talk proposal submission * 2020-12-31: Schedule published and speakers notified of acceptance * mid January 2021: Time frame for talk pre-recoding * 2021-02-06: Devroom taking place on-line Contact In case of any questions, comments and suggestions, please do not hesitate to contact the devroom organizers via the devroom's mailing list [3]. The primary organizers of the devroom in 2021 are: * Martin Decky * Jakub Jermar Links [1] https://fosdem.org/2021/ [2] https://penta.fosdem.org/submission/FOSDEM21/ [3] https://lists.fosdem.org/listinfo/microkernel-devroom [4] https://archive.fosdem.org/2012/schedule/track/microkernel_os_devroom.html [5] http://fosdem.microkernel.info/ [6] https://fosdem.org/ [7] https://fosdem.org/2021/practical/conduct/

1 0

Run SculptOS in i.MX8MQ-EVK
by fixed-term.christo.bita＠sojus-software.de 04 Dec '20

04 Dec '20

Hello all together, according to "Genode OS Framework release 20.11" SculptOS can run on the i.MX8MQ EVK board. I wanted to run the example so I did the following steps: 1)start the run Sculpt run-script tool/create_builddir arm_v8a cd build/arm_v8a make run/sculpt KERNEL=hw BOARD=imx8q_evk -after this a have an "image.elf" file in "BUILD_DIR/var/run/sculpt/boot" directory. 2)copy in the SD-Card dd if=image.elf of=/dev/"mySDcard" bs=1k seek=33 conv=fsync 3)select the boot device in the board Boot-Mode[3:0] = 0011 (SD card) The board is connected to a HDMI monitor. Unfortunately I don't get any log information. Maybe am I missing some middle steps or doing something wrong? Any help is very welcomed! Best regard, Christo

4 4

Announcement: Genode OS Framework version 20.11 released
by Norman Feske 27 Nov '20

27 Nov '20

We just released Genode version 20.11 today. With this version, we continue this year's overarching theme of supporting 64-bit ARM hardware. Thanks to intensive work on the framework's driver infrastructure and the actual device drivers, Sculpt OS has now become able to run on 64-bit ARM hardware, specifically the NXP i.MX8 EVK board. A second highlight of this release is the first version of our new CPU-load balancing mechanism, which aims at improving the CPU utilization when running complex multi-threaded workloads like a web browser on top of Genode. As with every Genode release, these major highlights are accompanied by many improvements throughout the framework, as listed here: - CPU-load balancing - Sculpt OS on 64-bit ARM hardware (i.MX8 EVK) - Multicore virtualization on ARM - VFS: Open Sound System ioctl emulation - VirtIO networking - Improved support for OpenBSD audio drivers - HWP support for recent PC hardware - NOVA: I/O-MMU support for AMD Please find the detailed release documentation at: https://genode.org/documentation/release-notes/20.11 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

question about Region_map::Region_conflict in attach_at()
by Alexander Tormasov 17 Nov '20

17 Nov '20

Hi! I have a problem in the following code (64 bit NOVA 20.08, 3GB RAM, with gdb): void Component::construct(Env &env) { Rm_connection rm(env); Region_map_client my_rm(rm.create(0x1400000)); char *_base = env.rm().attach(my_rm.dataspace()); Region_map_client my1_rm(rm.create(0x1000)); env.rm().attach_at(my1_rm.dataspace(), 0x102e000); log("my create managed dataspace", Hex((addr_t)_base)); } it return _base [11000000,12400000) and it give error during attach_at() call (which is far from requested address 0x102e000) Error: Uncaught exception of type 'Genode::Region_map::Region_conflict’ Why it is happens? Where this error generated in the NOVA code (or genode NOVA wrapper)? I assume that I can create 2 RM clients to be able to fill it (attach_to) ds later? Thanks! Sincerely, Alexander run file #debug go application via gdb # set build_components { core init timer lib/ld drivers/uart app/gdb_monitor lib/vfs/pipe noux-pkg/mmaptest } lappend build_components "lib/gdbserver_platform-$::env(KERNEL)" build $build_components create_boot_directory proc local_heap_default_size {} { return "0x1400000" } install_config { <config verbose="yes" ld_verbose="yes"> <parent-provides> <service name="ROM" /> <service name="LOG" /> <service name="RM" /> <service name="CPU" /> <service name="PD" /> <service name="IRQ" /> <service name="IO_MEM" /> <service name="IO_PORT" /> </parent-provides> <default-route> <any-service> <parent/> <any-child/> </any-service> </default-route> <default caps="200" /> <start name="timer"> <resource name="RAM" quantum="2M»/> <provides> <service name="Timer"/> </provides> </start> <start name="pc_uart_drv"> <resource name="RAM" quantum="2M" /> <provides> <service name="Uart"/> <service name="Terminal"/> </provides> <config> <policy label_prefix="gdb_monitor" uart="1" /> </config> </start> <start name="gdb_monitor" caps="4800"> <resource name="RAM" quantum="80M" /> <provides> <service name="mmaptest" /> </provides> <config verbose="yes" ld_verbose="yes"> <target name="mmaptest" caps="2800"> <config verbose="yes" ld_verbose="yes" local_heap_default_size="} [local_heap_default_size] {"> <vfs> <dir name="dev"> <log /> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" /> </config> </target> <preserve name="RAM" quantum="50M" /> <vfs> <dir name="dev"> <log/> <terminal/> </dir> <dir name="pipe"> <pipe/> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" pipe="/pipe"/> </config> </start> </config> } # evaluated by the run tool proc binary_name_gdbserver_platform_lib_so { } { return "gdbserver_platform-$::env(KERNEL).lib.so" } build_boot_image { core init timer ld.lib.so libc.lib.so vfs.lib.so libm.lib.so pc_uart_drv posix.lib.so stdcxx.lib.so vfs_pipe.lib.so posix.lib.so stdcxx.lib.so vfs_pipe.lib.so gdb_monitor gdbserver_platform.lib.so vfs.lib.so mmaptest }

2 6

Re: Running Genode on a Raspberry Pi 3
by Simon Himmelbauer 15 Nov '20

15 Nov '20

Hi Genodians, I just wanted to give a quick update regarding my issue with the random output on the serial line when running a Genode image from uboot on a Raspberry Pi 3. The issue was somehow caused by the Raspberry firmware. Downgrading to commit 204245361ea, which is the same version Tomasz used for his tests, fixed my problem. I have not identified yet which commit is actually responsible for the regression. Thanks to everyone, especially Tomasz, for dedicating the time to assist me! Best regards, Simon

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users