users

users@lists.genode.org

2357 discussions

Restart able block devices
by Uwe 30 Apr '21

30 Apr '21

Hello all, I have seen the Video (0). At the end there is the question how to make drivers for block devices restart able. The only limiting factor for this is state, according to the video. To store state in restart able processes raft(1) was invented. Especially this implementation has enough modularity to be adaptable to store its data on raw block devices. Another key part of the solution is transactional application of log segments. For this 3 fixed root blocks are needed. Every time you need to apply some segment to a root block you overwrite first a pointer (block number) in the root block with the address of the log segment you want to apply. >From this time on after reading something from that root block and anything pointed to from it you apply that segment. Ok, you will never implement it that way. You load a raft process with the data on restart and continue to run from this loaded data as if you had written that pointer this instant. Now you prepare the next root block by doing a cow operation on the data reachable from the old root block. At last you set the version field in the new root block and set the segment pointer to an empty value. Now you need to look at the version fields of all 3 root blocks on storage. There are 6 permutations of them but only one of them will fulfill the equation H(a,b)=c. (with H as a cryptographic hash) This permutation assigns to every one of the root blocks a letter. The letter a is for overwrite, the letter b is for backup and the letter c is for the current root block. The new version field is calculated H(b,c) and the new root is written to a. I think that allows fully transactional restart able block devices. The storage of the root blocks can but doesn't have to be on the same device of the Filesystem the root blocks are managing. (1)https://github.com/canonical/raft (0)https://video.fosdem.org/2021/D.microkernel/microkernel_pluggable_device_…

2 2

how to open elf file image from inside genode? libbacktrace question
by Alexander Tormasov 12 Apr '21

12 Apr '21

During port of libbacktrace code from gcc compiler I found that I need to be able to read a.out or similar file in runtime. This library try to read original executable file and parse it for functions addresses/etc, as a part of garbage collection for golang (it parse call stack in some specific way using gcc-specific calls). I have to port to genode the following code from src/lib/gcc/libbacktrace/fileline.c: for (pass = 0; pass < 5; ++pass) { int does_not_exist; switch (pass) { case 0: filename = state->filename; break; case 1: filename = getexecname (); break; case 2: filename = "/proc/self/exe"; break; case 3: filename = "/proc/curproc/file"; break; case 4: snprintf (buf, sizeof (buf), "/proc/%ld/object/a.out", (long) getpid ()); filename = buf; break; default: abort (); } best idea is to implement library call getexecname(), e.g. as a part of libc. Anyway, this is complex question, because we need to be able to open it and read a content later. How to configure this in run file? PS for better understanding why I need this - call stack where it is called, from gdb: #0 fileline_initialize (state=0x29000, error_callback=0x1198543 <error_callback>, data=0x405fe770) at /var/services/homes/admin/gen/21.02/contrib/libbacktrace-cabcd83bc903137f607eda3a65eb09feaa5f507e/src/lib/gcc/libbacktrace/fileline.c:102 #1 0x000000000119a9a5 in backtrace_pcinfo (state=0x29000, pc=0x1198610, callback=0x119808e <callback>, error_callback=0x1198543 <error_callback>, data=0x405fe770) at /var/services/homes/admin/gen/21.02/contrib/libbacktrace-cabcd83bc903137f607eda3a65eb09feaa5f507e/src/lib/gcc/libbacktrace/fileline.c:177 #2 0x000000000119accc in unwind (context=0x405fe420, vdata=0x405fe700) at /var/services/homes/admin/gen/21.02/contrib/libbacktrace-cabcd83bc903137f607eda3a65eb09feaa5f507e/src/lib/gcc/libbacktrace/backtrace.c:91 #3 0x00000000011a87e9 in _Unwind_Backtrace (trace=0x119abfc <unwind>, trace_argument=0x405fe700) at /genodelabs-genode-2491eee/contrib/gcc-3cade18cf9defeefa714aa91de3b157fbad4aa18/src/noux-pkg/gcc/libgcc/unwind.inc:307 #4 0x000000000119ada2 in backtrace_full (state=0x29000, skip=0x0, callback=0x119808e <callback>, error_callback=0x1198543 <error_callback>, data=0x405fe770) at /var/services/homes/admin/gen/21.02/contrib/libbacktrace-cabcd83bc903137f607eda3a65eb09feaa5f507e/src/lib/gcc/libbacktrace/backtrace.c:127 #5 0x0000000001198611 in runtime_callers (skip=0x2, locbuf=0xc42000e8d8, m=0x20, keep_thunks=0x0) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/runtime/go-callers.c:207 #6 0x00000000010fdf28 in runtime.callers (skip=0x1, locbuf=...) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/traceback_gccgo.go:56 #7 0x00000000010d8f7d in runtime.mcommoninit (mp=0xc42000e800) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:546 #8 0x00000000010db6c5 in runtime.allocm (_p_=0xc420008000, fn=0x121e298 <runtime.mspinning..f>, allocatestack=0x0) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:1466 #9 0x00000000010dbdb2 in runtime.newm (fn=0x121e298 <runtime.mspinning..f>, _p_=0xc420008000) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:1769 #10 0x00000000010dc360 in runtime.startm (_p_=0xc420008000, spinning=0x1) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:1925 #11 0x00000000010dc702 in runtime.wakep () at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:2006 #12 0x00000000010dfabf in __go_go (fn=0x10d72f2, arg=0x0) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:3144

5 17

Main menu of Sculpt/Genode too long to fit on screen
by reza.fathzadeh＠yahoo.com 09 Apr '21

09 Apr '21

Hello Genode developers, First of all, I have to say, Sculpt OS (and Genode framework in general) are one of the most interesting projects that I am extremely excited for their future. I ran into this issue, when you add a sufficient number of modules to a running sculpt instance, the main menu stretches outside the screen and without a way to scroll down, the only way to get them back is to remove some components. I was wondering if you are thinking of a better UI? Also, as 'depot' are frequently accessed and needed in a daily OS, would you think it'd be a good idea to bring organize 'depot' in a more accessible spot? Right now, you have to click many times. Thanks, Reza

3 2

Linux Driver Porting Advice
by John J. Karcher 08 Apr '21

08 Apr '21

Hello Everyone, I have been (very slowly) trying my hand at adding the missing Wacom touchscreen functionality to the "usb_hid" driver, and I am encountering some of the friction Stefan describes in his recent Genodians article on porting Linux drivers. (I have the additional handicap of not knowing what I'm doing, but that just makes it a learning experience. ;^) ) In that context, I'd like to ask for a little advice. Since the "usb_hid" driver is generally working, the main problem is implementing missing functions. After some fumbling, I have settled on commenting out sections of "dummies.c" and pulling more files in from the Linux source (rather than copying massive chunks into local files). To do this, I am adding files to "usb_hid.list", then doing "prepare_port dde_linux" and "make drivers/usb_hid". First question: Is this the right basic idea? Using this approach, I have been able to reduce the number of build errors. It looks like there are only a few left (although this could easily be a mirage). But I'm stumbling on conflicting headers, which has led me to an interesting discovery - the "build/x86_64/var/libcache/usb_hid_include/include/include/include/linux/" directory, which is filled with symlinks to "repos/dde_linux/src/drivers/usb_hid/lx_emul.h". Second question: Where is this controlled? I assume that if I pull in the real "device.h", for example, I should be able to remove "device.h" from a list somewhere that generates these symlinks. Is that correct? Finally, if anyone has any general advice, I'm all ears! Thanks! -- John J. Karcher devuser(a)alternateapproach.com

2 2

[set,get,make,swap]context from glibc for amd64 implementation and question for Norman
by Alexander Tormasov 08 Apr '21

08 Apr '21

as a part of efforts related to golang port I make separate patch for 21.02 genode related to implementation of setcontext/getcontext/makecontext/swapcontext family in libc as a base I borrow some code from glibc, and remove related files (mostly _ucontext.h/ucontext.h) from genode related 2 patches are in https://github.com/tor-m6/genode.git in 21.02 repo main one contains implementation to be applied to libc port aux patch contains only simple test for these functions, you can run it as I need also to add C support for alloc_secondary_stack/free_secondary_stack in dummies.cc to be able to use them during allocation of stack for makecontext/etc (it should work even in C files - current code do requires C++, I even can’t test patch without them). May be this is wrong place for the wrappers… current problems with the patch: is support only x86_64 (while can be easily extended to arm64) on nova (while should work on other OSes), and it do not support signals save/restore (while seems that not many of them supported by genode currently). Also some removal of code from libc is not that clear and correct (implement it in patch). Question for Norman (and may be other maintainers): is it suitable for main genode code, or I should keep patch only in my fork? Is it worth to make a pull request? Sincerely, Alexander

3 19

General Improvements for Sculpt
by Edoardo Mantovani 24 Mar '21

24 Mar '21

Hello everyone, Sorry for the late general reply, but I needed some days to elaborate on some of my ideas for Sculpt os. In those days I've tested almost every package available on depot, I must say some things referred for falkon browser: it is nice and probably the most interesting software in the entire distribution, but I think that disabling JS by default could be a really nice step for a more lightweight approach (which follows sculpt "style"), I've tested the frames and the browser speed through online tests and lichess duels, seems to go quite well, only small downside: sometimes it tends to stuck or stop the internet connection but is often a temporary problem, not persistent. PS I don't know why but when I've done the browser fingerprint, I found that the browser is effectively installed on Genode, have you set any identificative User Agent (or similar) for that? I don't know if "Chocolate Doom" is the homonymous video game, but unfortunately I wasn't able to play it cause an infinite "I_init: setting up machine state", the audio driver was the bsd_audio_drv while the wm was the themed_wm (internet connection under nic_router), do you know if I am doing anything wrong? I am not big fans of video games, but I would like to try it! Another few general considerations: the learning curve of Sculpt is pretty fast, I don't know why, but after few days I increased the feeling with the OS, the documentation played a fundamental role in it, Have you thought to implement also a touch screen mode for Sculpt? may be extremely interesting for smartphones. One good point is the "inspect" shell, fast and portable, I like it, only one problem: too few tools under /bin are available, apart vim, there is not many things you can do with it, my idea for fixing that could be to add few more useful tool: one idea could be the microsed implementation, it is around 25kb and permits to modify files through Regexp, only downside for this implementation: still many commands crashes (-e is an example). (sorry for the zip of the last time, I had not the idea of how peoples are suspicious on compressed files haha), the files are sed.h, sedcomp.c, sedexec.c and the relative Makefile; Another hint: upgrade the md5sum (maybe in the future) to something more secure, I don't know if Sculpt uses it for more complex (and security related) tasks but is strongly discouraged. I started to test the Xoroshiro PRNG you use for the OS internals, in general is quite secure, it is interesting to see its generation with a "0" seed. I'll search for some weakness on it in those days. Final suggestion: One day I tried to install as much software as I can on Sculpt, the result was quite strange, I wasn't able to scroll down the Leitz. enviroment, do you know if is possible to do it? { the photo is 5ECB60B5-C98C-496D-9A9D-ECB617AD6809 } Now I have more technical questions: Josef, I started yesterday studying how Genode handles wifi connections, it is almost identical to Linux, for the software stack (mac80211 and cfg80211) but I haven't understood why in firmware.cc ( the text file you linked to me ), in Fw_list struct some firmware images have NULL as available name while others have their correspondent name? Are still unimplemented some models ? I would like to start writing a software stack for BLE, any hints? Bluez could be a good starting point but honestly, I have no idea of how to port it on A non Unix system. Martin, I've finished the Wikipedia page translation, is the Wikipedia_it file, I've chosen to write it in Markdown language, let me know if is good. I've tried to adjust it as much as I can, let me know (I don't know if the format is legible by any Markdown interpreter). Norman, As the first thing, I've started to port a working Italian layout keyboard, the current version is in the email attachment (file: it_IT.chargen), only problem, certain letters are unavailable (like è, ò, à, ù, § and £), could you try to fix it? the big works for upper keys is already done and tested, (everything works well). Another few things to ask: Do you confirm that Sculpt, for now, has NO API or syscall available? it would be pretty useful for me to write tools in C with a nice syscall system, my idea could be to implement a programming language designed only for this OS which offers both high and low-level capabilities, (like Inferno's os Limbo programming language), I've started thinking on it, if you agree, in the next days I can try to design the main body of it (in PURE c, the best by test). Replaying the Bluetooth part: I agree with you, the big advantage you could gain by Bluetooth depot system consists on the practicality: think that the latest version of Bluetooth (5.0.X) can trace a device distance measurement by triangulation and, if we join this to the OBEX protocol, I think that a secure (and maybe native) application which show the nearest device which could act as depot server could be an interesting point, also think on the possible growth of a 24h connected (similar)"peer to peer" network system for discovering near possible Genode applications. [ Yes, not every device support BLE nor Bluetooth 5.0.X but for an incoming future could be a great idea] Let me know what you think, Regards, Edoardo Mantovani, 2021 -- Edoardo Mantovani Independent security researcher email: Baseband(a)cpan.org Urbino, Italy

7 37

error when trying out cbe
by Stefan Thöni 19 Mar '21

19 Mar '21

Hi Genodians I'm currently looking into CBE and have read the articles and release notes about it. Now I'm trying it out using the vfs_cbe_init and vfs_cbe runscripts on genode 21.02. When running vfs_cbe i get the following error: [17:28:25.837] [init -> initialize_cbe -> init -> vfs_cbe] Error: Exception raised: explicit raise in cbe-block_io.adb:753 [17:28:25.837] [init -> initialize_cbe -> init -> vfs_cbe] Error: Uncaught exception of type 'Ada::Exception::Program_Error' What am I missing? 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 4

What I want to do.
by Michael Grunditz 08 Mar '21

08 Mar '21

Hi Genodians, I would like to tell you what I am trying to achieve. I want to have Genode as a service system for RISC OS. When aarch32 is dropped from Cortex cpu's it will also provide emulation services. Right now I run RISC OS fully natively on core 1 and Genode on core 0 (A53). The reason for doing this on iMX8M is that it , since a week or so , is supported by both systems. Besides drivers , I also want to take advantage from some apps. A good example is a webbrowser. Genode is much better suited to run such applications. The idea is to run render and network tasks on Genode , but with a RISC OS allocated buffer as its framebuffer. On RISC OS it will look and feel like a native app. It will also be a base for converting RISC OS kernel to C. By trapping SWI's from RISC OS to Genode I can implement them in C/C++. The goal is to have as much as possible running natively on aarch64. Today the RISC OS kernel is assembler. I want to keep the RISC OS experience as it is today, and this hybrid solution is a experiment to see how it all can be solved. If you don't like this project , please tell me now! -- Michael Grunditz Sent from my RISC OS workstation..

4 10

Genode at virtual FOSDEM 2021
by Norman Feske 08 Mar '21

08 Mar '21

Hello everyone, the annual FOSDEM in Brussels and the microkernel developer room in particular is almost a mandatory date for us. Instead of gathering in Brussels, this year, crowds of Free-Software and Open-Source enthusiasts will hold a virtual event. The FOSDEM organizers are restless with setting up virtual counterparts of important FOSDEM features like developer rooms and even hallway meetings. FOSDEM is free for everyone. FOSDEM 2021, February 6 and 7 https://fosdem.org/2021/ The microkernel developer room is shepherded by Martin Decky of the HelenOS project, who announced a call for participation in November. You may have noticed his posting on this mailing list. It goes without saying that we at Genode Labs urged to contribute. In the meantime, the schedule of the developer room has been decided. https://fosdem.org/2021/schedule/track/microkernel/ The topic of our contribution is the presentation and demo of our recent developments of pluggable device drivers, which will be the basis for on-the-fly driver updates, self-healing, and power management. Saturday, February 2, 13:05 "Pluggable device drivers for Genode" Norman Feske https://fosdem.org/2021/schedule/event/microkernel_pluggable_device_drivers… The developer room will close with a panel discussion among several participating projects including Genode and moderated by Martin Decky. Saturday, February 2, 15:05 "State of Microkernels in 2021" https://fosdem.org/2021/schedule/event/microkernel_state_in_2021/ See you at virtual FOSDEM 2021! 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

3 4

cpu specific kernel call
by Michael Grunditz 05 Mar '21

05 Mar '21

Hi, I have a kernel call that starts RISC OS, and uses psci. I wonder , where should I put that very aarch64 dependent code. I somehow need to be able to call it from userspace. Regarding kernel calls in general , what is the best way of calling them? Right now I do "MOV x0,#number ; SVC" , probably not very Genode style! :) -- Michael Grunditz Sent from my RISC OS workstation..

3 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users