users

users@lists.genode.org

9 participants
2333 discussions

GCL component and repository
by Stefan Thöni 21 Feb '20

21 Feb '20

Hi Genodians We would like to release a new component under GCL. Should we place it in genode-world or create our own public repository? It the latter is the case, is there any place where you collect public repositories containing GCLed genode code? 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 1

LTE Chips and Genode
by Sid Hussmann 13 Feb '20

13 Feb '20

Dear Genodians, does anyone of you have experience in dealing with LTE chips? From my perspective it's unclear which path to take. Should I use a chip that connects via PCIe and port a linux driver? Or should I use one that I can connect serially using AT commands? Is there a component that abstracts the modem use-case for data transfer? Or is USB the way to go? Yours truly, Sid -- Sid Hussmann CTO & Founder gapfruit AG Baarerstrasse 135 6300 Zug - Switzerland sid.hussmann(a)gapfruit.com

2 1

Roadmap 2020
by Norman Feske 23 Jan '20

23 Jan '20

Dear Genode community, the year 2020 is approaching, which prompts me to kick off the discussion of our road map for the year to come. Before drafting plans, however, I'd like to share my personal reflections of the past 12 months. For the road map 2019, we picked "bridging worlds" as our guiding theme: (1) Lowering the friction when combining existing software with Genode, (2) Fostering interoperability with widely used protocols and APIs, and (3) Making Genode easier to approach and generally more practical. With respect to (1), we identified Genode's custom tooling (build system, run scripts, ports mechanism, depot tools) as a point of friction. They are arguably powerful and flexible but require a lot of up-front learning. This is certainly a burden unacceptable for a casual developer without a black belt in Make and Expect/Tcl. The new Goa tool rearranges the existing tools in a way that puts the concerns of casual developers into focus, allowing for the use of commodity build systems, eliminating Tcl syntax from the equation, running sub-second test cycles, and streamlining the packaging of software. On account of (2), we switched to C++17 by default, fostered the use of Java, updated Qt5, and put POSIX compatibility into the spotlight. We were eventually able to dissolve the need for our custom Unix runtime (Noux) because all features of Noux are covered by our regular libc now. Our biggest step towards (3) is the https://genodians.org website we started in winter 2019, which gives individual members of our community an easy way to present thoughts, projects, and experiences. Complementing Genode's formal documentation, it also conserves practical tips and tricks that were previously not covered in written form. When speaking of "bridging worlds", I should not forget to mention the tremendous effort to bring Sculpt-OS-like workloads to the 64-bit ARM world. Thanks to the added support for multi-core AARCH64, hardware-based virtualization, and network/USB/graphics drivers for the i.MX8 SoC, the flexibility of Sculpt OS will eventually become available on PC hardware and ARM-based devices alike. Over the course of 2019, we admittedly skipped a few topics originally mentioned on our road map. In particular, the user-visible side of Sculpt OS received less attention than originally envisioned. We also deferred several ideas we had in mind about reworking our GUI stack. Instead, we expanded our work in the areas of storage (block-level APIs, test infrastructure, block encryption) and input processing. This shift of focus is mostly attributed to the priorities of Genode Labs' customers who fund our work. Drafting plans for 2020 ----------------------- Hereby, I'll just present my personal interests and invite you to do the same. When carving out Genode's official road map for 2020 until mid of January, I will then try to condense all the input into a tangible plan. Personally, I think that after "bridging worlds", it's time for "use, consolidation, and optimization". - It is certainly too early to call Goa a success. In order to find out if we are on the right track, I want to expose Goa to as many problems as possible, primarily by the means of porting software. - I'd love to pick up our ideas about Genode's GUI stack, accommodating headless scenarios, multi-head, screen capturing, color depth, and the ability to restart drivers. - I have a huge backlog of ideas about the user-visible side of Sculpt OS, which would make Sculpt OS more pleasant to use and much more fun. E.g., - Replacing Unix/Vim-based interface of the Leitzentrale with a graphical user interface - Making the Leitzentrale's layout more logical - Keyboard-based navigation - Context-aware on-screen documentation - Settings embedded in the graph nodes of the runtime view - I see plenty of opportunities for optimization throughout the entire software stack. With the rich C runtime in place now, it becomes easier than ever to stress the system from various angles, which is a great motivator for optimization work. - Genode's binary compatibility across a variety of kernels is a key feature of the framework. I'd like to push it even further by unifying the capability-space management among all the kernel platforms. Such a consolidation would make Genode less reliant on the subtle ways how edge cases are handled by each kernel (in-kernel data structures, capability re-identification), and reduce the amount of kernel- specific code to maintain. This is merely my personal point of view. Now I'm very interested in learning about your's! Please don't hesitate to share your perspective on the project, your priorities and plans, and topics you would anticipate most. 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

15 34

ROM with size information
by Stefan Thöni 20 Jan '20

20 Jan '20

Hello Genodians For our current use case we need to provide a single file e.g. continuous binary data with size information to a component. We cannot use to standard ROM session as it doesn't provide size information. We also need the ability to specify a file not known at development time through the session label in the deploy config as is possible with the fs_rom component. We have discussed several solution strategies: a) Provide the file through a file system session: Besides the drawback of unnecessary complexity this also does not give us the ability to specify the desired file with the session label. b) Add content size information to the ROM session and update the fs_rom component to provide it. This would seem the most straightforward solution, but for the sacredness of the ROM session. c) Create an updated or forked fs_rom component with the ability to provide single files as tar archives. This would allow us to consume the tar with vfs and have the size information available. Which strategy should we prefer? Are there any other solutions that satisfy our requirements? Best regards Stefan -- Freundliche Grüsse Stefan Thöni Chairman of the Board Senior Security Architect gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 1

How to terminate correctly program?
by Alexander Tormasov 07 Jan '20

07 Jan '20

I try to finish a program with a lot of threads (eg 6). In particular, it call libc exit(0) from one of them. Then seems that it start to free memory , and one of threads accidentally receive timer event, and try to access its own memory - and fail because it already became inaccessible. Unfortunately I do not have normal control over it (this is just a behavior of golang “hello world” program!) Can I forcible cancel all timers/signals inside program threads and stop all activities to avoid such problems? Better without races ;) Sincerely, Alexander

2 1

Re: Roadmap 2020
by ttcoder＠netcourrier.com 03 Jan '20

03 Jan '20

Responding in terms of "use cases", I would list the following two, as use-cases of interest to me: 1) making my radio station software cross-platform, to also run on a Genode-based system (not necessarily a full fledged OS, just framebuffer + nit picker + audio_drv to start with) 2) transferring a bit of my day-to-day computer use, from Haiku to a Genode-based operating system. That OS would be(come) as full fledged as possible over time; and would mix Sculpt-OS's no-holds-barred safety and use of Genode's security features, whilst still providing the great productivity I'm used to. Regarding the former, I'm happy to have reached a stage where we have a "vertical slice" of CC6 running on Genode. And since early Q3 2019 it is now in "maintenance" mode, i.e. whenever I make changes to CC6 in Haiku, I also compile it in Genode+haiku.lib.so to check that it builds and runs as before (and if not, I add implementation or at least stubs for the missing symbols). Once we go public with CC6 (Any Day Now (tm)) and reveal what it looks like in the Haiku world there'll be more info about the state of its Genode counterpart as well. Future plans include looking into the AHCI driver (it locks up on our production AMD F2A systems, so I can only work on a thinkpad for now) and bringing the haiku.lib.so library to parity with its "big brother", to have more than a proof of concept/vertical slice. Regarding the latter, That one is still on the drawing board. Future plans include a full-fledged desktop similar to the one I use daily, and maybe also an hpkg-like packagefs that allows to mount/unmount packages (packagefs is like BFS -- once you get the virus you can never go back :-). It would have to settle on a preferred file system, I'm leaning on NTFS (via ntfs-3g) as the one that seems to provide the features needed for a modern desktop OS and is provided by seemingly mature OSS code base. Later in Q1 and Q2 2020, after crunch time has passed, I'll take baby steps resuming work on this, starting with cleaning up and commiting more files to the public repository on ChiselApp. *** Now to put back the spotlight where it belongs, on Genode Labs : Congrats on folding "noux" into libc; following (some of) the action on github it's been clear it was a lot of hard work! It's exciting reading the "Goa" article series. Definitely keeping it as a reference. In fact, I don't know if Norman realizes how many benefits it brings beyond just presenting the Goa tool : for people who live and breathe Genode daily it's probably all old news, but for devs like me it's great that is revisits the functioning of Genode system, Genode's packaging, a lot of System Integration aspects (the "config" file ..etc) in a way that is different from the previously available documentation. Lots of aspects that need to be hammered home. Those articles are all very welcome... and bookmarked. They seem to strike the perfect balance in detailing what must be, and yet remain super readable. And once armed by a better understanding, one may then revisit the other Genodians articles, and "get" more from them, than initially understood during the first read! > - It is certainly too early to call Goa a success. In order to find out > if we are on the right track, I want to expose Goa to as many problems > as possible, primarily by the means of porting software. Having a rich set of ported software is very attractive, it has a lot going for it. Of course one has to strike a balance between porting a lot and then adding what could be perceived as "dead weight" and being too conservative, porting too few programs... But if there are no big down sides I'd say go for it. > - I'd love to pick up our ideas about Genode's GUI stack, accommodating > headless scenarios, multi-head, screen capturing, color depth, and the > ability to restart drivers. The latter is intriguing ; that would go a long way toward demonstrating yet again the technological superiority of a micro- kernel component-based OS -- I can think of a couple drivers/FSes I'd be glad to see "ruggedized" by that feature. The GUI stack aspect is of course something I would monitor closely, hoping to contribute both ideas and code in one shape or another. Cedric

2 1

Handling EOF on stdin
by Sid Hussmann 15 Dec '19

15 Dec '19

Dear Genodians, we have a scenario where a java application reads from stdin and writes to stdout and stderr. In our current implementation a component provides a terminal session and a log session to where the jvm connects stdin, stdout and stderr accordingly. The java application needs to know when the input of data on stdin is finished. From the java applications perspective this is easiest done by reading until a EOF signal is received. So a first tempting approach to this problem would be to extend the Terminal session interface with a signal handler for EOF. However... I'm hesitant to touch such a prominent session. Is there an other approach to this? Maybe using the newly released vfs pipe plugin? Or via emulation of POSIX signals? Yours truly, Sid -- Sid Hussmann CTO & Founder gapfruit AG Baarerstrasse 135 6300 Zug - Switzerland +41 79 543 46 41 sid.hussmann(a)gapfruit.com

2 5

TLS and single/posix thread model in gcc for genode
by Alexander Tormasov 13 Dec '19

13 Dec '19

By default, gcc compiled by toolchain says that thread model is single. Is it correct? In particular, what’s with TLS (thread local storage), do we need TLS being enabled via —enable-tls option? I run some programs with TLS support in multi thread environments (golang runtime)... now it have a race when variable which should be in TLS (in accordance with comments, like in getg() current g) sometimes return null. I am not sure - may be this is related to TLS support, may be in locking... If I try just to add option --enable-threads=posix toolchain compilation stop giving Error In file included from /home/alexs/genode_test/genode/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/gthr.h:148, from /home/alexs/genode_test/genode/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/libgcov-interface.c:27: ./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory #include <pthread.h> ^~~~~~~~~~~ compilation terminated. Makefile:921: recipe for target '_gcov_dump.o' failed Any suggestions? Should TLS work in genode over Nova “as it is”?

2 1

x86 virtualization on Ryzen
by Nobody III 29 Nov '19

29 Nov '19

With the relatively new generic virtualization interface, Seoul is now able to run on my AMD Ryzen machine. However, VirtualBox still crashes when starting the VM. With the NOVA-specific interface, it would die from an unresolved page fault, while with the generic interface, it throws a general exception that doesn't seem to give much information. I don't have the log on hand right now; otherwise I would specify the exception. What differences are there that could make VirtualBox fail while Seoul works fine? My UEFI version should be new enough to have the Ryzen CPUID issue patched, so that shouldn't be the problem, but I don't know how to empirically rule that out.

1 0

Announcement: Genode OS Framework version 19.11 released
by Norman Feske 28 Nov '19

28 Nov '19

We just released the version 19.11 of the Genode OS Framework. The highlights of this version are the prototype of a custom block-device encrypter implemented in SPARK, virtualization of 64-bit ARM platforms, new tooling especially geared towards the porting and development of application software, and much improved POSIX compatibility. Summary: - New (preliminary) block-device encryptor - New virtualization of 64-bit ARM platforms - New tooling for application development - Enhanced POSIX compatibility - More supported Intel wireless devices - Multi-core 64-bit ARM - Self-hosting on 64-bit ARM The background stories and technical details of those topics are covered in depth by our release documentation: https://genode.org/documentation/release-notes/19.11 I wish you a lot of fun with exploring the new version! 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:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users