users

users@lists.genode.org

7 participants
2314 discussions

Can't run runscript gdb_monitor_interactive
by Alexander Tormasov 25 Oct '19

25 Oct '19

hopting to have working gdb to debug apps inside gendode I try to compile gdb_monitor_interactive for nova kernel x64 I use 19.8 version, make -C build/x86_64/ VERBOSE= VERBOSE_MK= VERBOSE_DIR= MAKEFLAGS=--trace KERNEL=nova run/gdb_monitor_interactive I use symlinks to assemble genode dir (mounted inside build VM from host). In log I found genode build completed checking configuration syntax can't read "init_xsd_file": no such variable while executing "check_config init [run_dir]/genode/config $init_xsd_file init $xsd_files $xsd_inc 0" (procedure "build_boot_image" line 32) invoked from within "build_boot_image $boot_modules" (file "/genode.08/repos/ports/run/gdb_monitor_interactive.run" line 93) invoked from within "source $include_name" ("foreach" body line 6) invoked from within "foreach include_name [get_cmd_arg --include ""] { # first check if the include name is absolute if {[string first "/" $include_name] == 0} { puts ..." (file "genode/tool/run/run" line 1006) Makefile:323: recipe for target 'run/gdb_monitor_interactive' failed make: *** [run/gdb_monitor_interactive] Error 1 I check availability of file, it is accessible (at least less can open it from guest VM where I run script) ~/genode/build/x86_64/bin/init.xsd -> ~/genode/repos/os/src/init/config.xsd Probably this portion of run script fail: # determine which XSD file to use for the init config foreach xsd_file $xsd_files { set filename [file tail $xsd_file] if {$filename == "init.xsd"} { set init_xsd_file $xsd_file } } Any suggestions?

2 1

grpc server causes deadlock in libc
by Stefan Thöni 25 Oct '19

25 Oct '19

Hello Genodians We have ported google protocol buffers and the Google RPC (grpc) to genode and would like to contribute that to genode world. We encountered a problem with the port in which grpc server deadlocks when using the poll function of libc to poll sockets via the lwip or lxip plugin. We determined that poll calls Libc::suspend in task.cc which in term calls Pthreads::suspend_myself where the deadlock oocurs at myself.lock.lock();. Note that the grpc server uses several threads which apparantly are all waiting/suspended when the problem occurred. You can check out or working branch at https://github.com/trimpim/genode-world/commit/18da8122f805de0a137b778a6d83… and execute scenario using run/grpc runscript reproduce the problem. Does anyone has any idea why a deadlock might occur in that situation? Kind 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

java applications and stdin
by Duss Pirmin 23 Oct '19

23 Oct '19

Hello Genodians I'm trying to use the stdin file descriptor in a java application to pass data through a terminal to the application. When the application tries to read from the file descriptor, I get the following error message: [init -> init -> java] Error: no plugin found for read(0) If is start a libc component instead of java, there is no error message and the component can read from stdio. In the <start> node of the java application I have the following <config> node: <config ld_verbose="no"> <arg value="/bin/java" />  <arg value="-Xint"/> <arg value="-jar"/> <arg value="app.jar"/> <libc stdin="/dev/terminal" stdout="/dev/terminal" stderr="/dev/log" rtc="/dev/rtc"/> <vfs rtc="/dev/rtc"> <dir name="dev"> <log/><null/><inline name="rtc">2000-01-01 00:00</inline> <terminal label="terminal"/> </dir> <dir name="bin"> <rom name="java"/> </dir> <dir name="lib"> <rom name="java.lib.so"/> <inline name="jvm.cfg">-server KNOWN -client IGNORE </inline> <dir name="server"> <rom name="jvm.lib.so"/> </dir> </dir> <dir name="modules"> <tar name="classes.tar"/> </dir> <tar name="app.tar"/> <rom name="zip.lib.so"/> <rom name="nio.lib.so"/> <rom name="net.lib.so"/> </vfs> </config> Can anybody help me getting this to work? Best regards, Pirmin

2 2

Depot autopilot vs base-linux with seccomp and per-session socket
by Stefan Thöni 10 Oct '19

10 Oct '19

Hello Genodians I ran into some trouble using seccomp and the base-linux per-session sockets with the depot autopilot. First the depot autopilot uses significantly more distinct syscalls and I dont quite understand why that is. The syscalls used above those used by the basic test-log are: clone, getpid, sigaltstack, rt_sigaction, gettimeofday, nanosleep Can anyone explain why these are nessecary? The other problem I couldn't solve up to now is that the depot autopilot seems to use many more sessions than the scenario itself. Even for the basic test-log scenario at least 512 sessions are used by a single process as it fails due to running out of socket descriptors when a socketpair per session is used. Can anyone explain this behavior? Might there be stale sessions (leak) in the depot autopilot? 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 1

Next Step For Sculpt On New ThinkPad
by John J. Karcher 09 Oct '19

09 Oct '19

Hello, As I hoped, by copying the files from the Sculpt USB stick to my NVMe Ext2 partition, I can now boot into Sculpt on the ThinkPad L380 Yoga (using Norman's USB HID-disabling patches). The results are basically the same as booting from from USB, but hopefully this will allow me to load local packages and save log files to the NVMe partition. Does anyone have any ideas on what I can try, in order to generate some useful output? To recap, the most important limitations at the moment are 1) the the Inspect window doesn't open, and 2) I can't connect to a network. Thanks! -- John J. Karcher devuser(a)alternateapproach.com

2 3

CfP: FOSDEM 2020 - Microkernels and Component-based OS devroom
by Julian Stecklina 04 Oct '19

04 Oct '19

[Resent due to wrong Reply-To: header] FOSDEM 2020 - Microkernels and Component-based OS devroom CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2020 [1] in Brussels, Belgium 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-, unikernel-, and component-based operating systems. Possible topics 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 and tools * enabling support for hardware (architectures, device drivers) * enabling support for programming languages * maintenance and testing * security and robustness * trends and challenges * use cases, experiences, lessons learned and demos The deadline for your proposal is on December 1, 2019. Please use the Pentabarf [2] system to submit your proposals. You do not need to create a new account if you already have one. Make sure to include the following in your proposal: * title of your talk (will be printed in the FOSDEM booklet) * your full name (will be printed in the FOSDEM booklet) * a short abstract (one or two paragraphs) * duration of your talk (at least 25 and no longer than 55 min) The official devroom schedule (along with the accepted talks) will be announced on December 15 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 invited to send any other suggestions for what you want to see or do at the devroom to the list. We will also use this list to organize the traditional devroom dinner that will happen on the first day of FOSDEM. About the devroom Since the first Microkernel devroom at FOSDEM 2012, this devroom has been part of each following FOSDEM. The focus gradually widened to include component-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. Social events It also has become a habit that the microkernel projects dine together somewhere in Brussels. The year 2020 will not be any different, so there is going to be a dinner on Saturday night. We try place a reservation, so we will inform you about the exact location and time later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors 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 discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. Important dates recap * 2019-12-01: Deadline for submissions * 2019-12-15: Schedule published and speakers notified of acceptance * 2020-02-01: Devroom Dinner (details to be announced) * 2020-02-01/2020-02-02: The devroom takes places (check the schedule) Links [1] https://fosdem.org/ [2] https://penta.fosdem.org/submission/FOSDEM20 [3] https://lists.fosdem.org/listinfo/microkernel-devroom

1 0

CfP: FOSDEM 2020 - Microkernels and Component-based OS devroom
by Julian Stecklina 04 Oct '19

04 Oct '19

FOSDEM 2020 - Microkernels and Component-based OS devroom CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2020 [1] in Brussels, Belgium 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-, unikernel-, and component-based operating systems. Possible topics 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 and tools * enabling support for hardware (architectures, device drivers) * enabling support for programming languages * maintenance and testing * security and robustness * trends and challenges * use cases, experiences, lessons learned and demos The deadline for your proposal is on December 1, 2019. Please use the Pentabarf [2] system to submit your proposals. You do not need to create a new account if you already have one. Make sure to include the following in your proposal: * title of your talk (will be printed in the FOSDEM booklet) * your full name (will be printed in the FOSDEM booklet) * a short abstract (one or two paragraphs) * duration of your talk (at least 25 and no longer than 55 min) The official devroom schedule (along with the accepted talks) will be announced on December 15 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 invited to send any other suggestions for what you want to see or do at the devroom to the list. We will also use this list to organize the traditional devroom dinner that will happen on the first day of FOSDEM. About the devroom Since the first Microkernel devroom at FOSDEM 2012, this devroom has been part of each following FOSDEM. The focus gradually widened to include component-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. Social events It also has become a habit that the microkernel projects dine together somewhere in Brussels. The year 2020 will not be any different, so there is going to be a dinner on Saturday night. We try place a reservation, so we will inform you about the exact location and time later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors 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 discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. Important dates recap * 2019-12-01: Deadline for submissions * 2019-12-15: Schedule published and speakers notified of acceptance * 2020-02-01: Devroom Dinner (details to be announced) * 2020-02-01/2020-02-02: The devroom takes places (check the schedule) Links [1] https://fosdem.org/ [2] https://penta.fosdem.org/submission/FOSDEM20 [3] https://lists.fosdem.org/listinfo/microkernel-devroom

1 0

depot_autopilot, log/serial, docker and reboots
by Roman Iten 03 Oct '19

03 Oct '19

Hello For continuous testing, I have a docker container in which the depot_autopilot run script is executed. For ARM targets, I include `log/serial` which executes `picocom`. It works like a charm until the point where the run script reboots the target and tries to reconnect to the serial port which is still busy. `ps` reaveals that picocom is still running, although it should have been killed by then. Please note that this only happens when the run script is executed within a docker container... After tinkering around with it, I came up with this patch [1]. It works for me when executing the run script "directly" as well as within the docker container. But to be honest, I don't understand why (...it's only required in a docker environment). I'd feel better if someone can confirm that the patch is reasonable or how else to solve the problem. Thanks, Roman [1] https://github.com/rite/genode/commit/c4c7bf56230d18480d672ba432d6958ff72ec…

1 0

Thread switching in Genode/seL4 and registers and utcb access problem
by Alexander Tormasov 27 Sep '19

27 Sep '19

I am trying to get working getcontext/setcontext/makecontext prototype on seL4/Genode (I can’t use anything except seL4 in this moment due to some reasons). I need both for x86_64 and aarm64 arch. I started from x86. So, question one. May be someone know kind of rough implementation for user-space context switching? I read information that this is not implemented yet in the main genode - but may be some projects does this already? Problem 2. When I start trying to make a fast solution and try to read registers and some info from low level physical seL4 thread using seL4_TCB_ReadRegisters I found that: In returned successfully data rip register is always 0 for current thread, tcb selector myself.native_thread().tcb_sel also 0, and rsp = 0x13! Probably I can’t read myself? Problem 3. I try to take address of IPC buffer bounded to utcb() field of Genode::Thread using code below. It successfully compiled and linked. Anyway, in attempt to run the program I found the following error in log: [init -> test-go] Error: LD: jump slot relocation failed for symbol: 'Genode::Thread::utcb()’ While access for similar fields in the same Thread structure successfully works! Eg Name name() const; can be printed, native_thread() also give results. I even found in the .o file the name of field (function technically) marked as U , and literally the same name mangled in the sym file for ld.lib.so compiled: 000000000003a09a T _ZN6Genode6Thread4utcbEv genode/repos/base/lib/symbols/ld:_ZN6Genode6Thread4utcbEv T How to fix this? // take info about genode thread Thread &myself = *Thread::myself(); log("myself ", &myself, " size ", sizeof(myself)); addr_t const ipc_buffer = reinterpret_cast<addr_t>(myself.utcb()); log(" name ",myself.name(), " sb ", myself.stack_base(), " svb ", myself.stack_area_virtual_base(), " tcb ", (addr_t)myself.native_thread().tcb_sel); seL4_IPCBuffer &ipc_buffer = *reinterpret_cast<seL4_IPCBuffer *>(myself.utcb()); Sincerely, Alexander Tormasov・

4 9

Sculpt Hanging On New ThinkPad
by John J. Karcher 25 Sep '19

25 Sep '19

Hello, I recently got a new mid-range ThinkPad, which I would love to use as a Genode "daily driver". As you can imagine, one of the first things I did was to try to boot up a Sculpt USB stick. (I tried the 19.07 image, and built a fresh image straight from GitHub, both with the same result.) The system boots into Leitzentrale, with the Manager window, log area, and even component graph all displaying. But then it freezes, not accepting keyboard or mouse input. (It may be related to the USB controller, because 1) the USB stick drive either shows a size of 0 bytes or doesn't display at all, and 2) moving the mouse while Genode is starting seems to cause the system to freeze before Leitzentrale is displayed.) Does anyone have any thoughts on this? Is there a diagnostic tool I can run to give more useful info? I will be happy to give more details on the hardware in the appropriate forum. Should I open a GitHub issue? Thanks! -- John J. Karcher devuser(a)alternateapproach.com

2 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users