users January 2020

users@lists.genode.org

15 participants
5 discussions

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users January 2020