users

users@lists.genode.org

5 participants
2338 discussions

Sculpt for slides presentation
by Roman Iten 03 Mar '20

03 Mar '20

Hello Norman Thanks for the inspiring Talk about the new Sculpt version. During this talk, you switched between the leitzentrale, runtime and slides layers. I tried to do the same, but failed. I can show a PDF using pkg/pdf_view by routing it - for example - to "themed wm" or "background". How can I use the "slides" layer and how do I can make sure the PDF is shown with "optimal" zoom level (page with/height)? How can I toggle the slides layer on and off? Thanks, Roman

2 2

Announcement: Genode OS Framework version 20.02 released
by Norman Feske 28 Feb '20

28 Feb '20

I'm happy to announce the version 20.02 of the Genode OS Framework. The topics of this release were strongly motivated by Sculpt OS. As one break-through, it brings the entirety of Sculpt to 64-bit ARM hardware, including all device drivers needed for the i.MX8 SoC, and featuring even hardware-assisted virtualization. At the user-facing side, the release features a largely redesigned administrative user interface for Sculpt along with many collateral improvements regarding the overall system performance and framework infrastructure. Speaking of the latter, the release features the long anticipated library version of the init component, which eases the creation of multi-component applications following the design principles of Genode. The topics outlined above scratch only the surface. There is much more to discover: Summary: - Redesign of the user interface of Sculpt OS - Sculpt OS on 64-bit ARM i.MX8 hardware - New sandbox library for multi-component applications - VirtIO support for ARM virtual machine monitor - Virtual desktops - Enhanced GUI widget rendering - Performance optimizations - Faster XML parsing - Diminished idle load of the Seoul VMM - Lower IPC latency of the base-hw kernel - POSIX compatibility improvements - Migration to modern block-device API - Updated audio driver based on OpenBSD 6.6 - Genode running on bare-bone Linux kernel Read the complete release documentation for the version 20.02 at https://genode.org/documentation/release-notes/20.02 Have fun while 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

Qt5 build tools
by Nobody III 27 Feb '20

27 Feb '20

I'm trying to port Qt5 software to Genode. The lack of qmake support is problematic, as most qmake project files I've encountered cannot be handled by GNU make as regular makefiles, which is the standard method used by Genode's build tools. Aside from qmake, the other most common build system I've encountered being used by Qt5 software is CMake. Support for using either (or ideally both) of these with Goa (or the Genode SDK) would be very helpful. I recognize that Goa already has basic CMake support, but the CMake files for Qt5 aren't being generated (or aren't being kept) when Qt5 is built using Genode's build system, so CMake is not yet a viable option for building Qt5 software using Goa. Ideally support for both systems should eventually be pursued, but either one would be extremely useful. Can someone help me with this?

2 1

virtual memory usage of base-linux components
by Duss Pirmin 25 Feb '20

25 Feb '20

Hello Genodians I'm running a scenario on base-linux on a system that has virtual memory over commit disabled. While debugging startup problems of this scenario on the target system I realized that at "random" components didn't start without any hints in the log. `strace` showed that the component that wasn't running (often timer) was terminated very early with SIGSEGV. A look at htop showed that each Genode component uses about 420 MB of virtual memory. lx_hybrid components on the other hand "only" about 170 MB. Can anybody give me some hints on where should start my quest to reduce the virtual memory footprint of Genode components on base-linux? Regards, Pirmin

2 2

Wifi drivers in Sculpt OS
by Colin Parker 22 Feb '20

22 Feb '20

Hello, I am new to Genode/Sculpt and have been trying to get it working on my somewhat old Mac Mini. I eventually succeeded to make it boot, by disabling some unnecessary drivers like PS2. However, wifi doesn't work, and I would like that feature. There is an internal wifi card in the computer that doesn't work on Linux, so I bought a USB dongle that I've been using (with Linux). From looking at some of the source, it seems most of the drivers are brought in from Linux, but, I'm not sure if or how wifi usb is supported. There's a usb_net.list but I can't figure out if it includes wifi. Is this something that would be easy to add? Is bringing drivers over a pretty simple process like copying a few files or is it an extensive effort? Thanks in advance for your suggestions. Colin

3 8

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users