users

users@lists.genode.org

1 participants
2310 discussions

23 Jan '21

Hi, I hope that it is not too late to ask your community to consider very seriously the matter of stealing focus that other OS/DEs suffer from. To be more precise, after starting my computer I choose 5 apps to get opened. While they are opening I choose the 2nd one (which opened) to work with. Now, the other 3 apps should complete start without coming forward and interrupt my work. They just appear in the task bar, either flashing, lighting or not. This feature would also be a general option, like: "Allow stealing focus: false/true". Thanks in advance. PS: "Always on Top" is not a SERIOUS solution at all!!! Discussing with some DE developers I was told that it is a matter of OS and not of DE. OS allows app windows to comes up.

2 1

Install Genode on desktop PC
by Edoardo Mantovani 23 Jan '21

23 Jan '21

Hi for everyone! I am new to Genode os, I've tried it for an once and I found it beautiful, but honestly I still don't know if (and how) I can install it on "my hardware's " pc. (I am currently using Sculpt 20-08) Please Helps, Regards, -- Edoardo Mantovani Independent security researcher email: Baseband(a)cpan.org Urbino, Italy

3 3

Sculpt 20.11 - Blank Screen On ThinkPad Convertible
by John J. Karcher 20 Jan '21

20 Jan '21

I don't know if anyone else is experiencing anything like this, but I am getting a blank screen after booting Sculpt 20.11 on my ThinkPad L380 Yoga. The mouse pointer does display (and move), so the system is alive, but Leitzentrale never appears. 20.08 worked fine. FWIW, I built a version from Master last week, but that has the same result. Is this a known issue? Is there anything I can reconfigure, etc.? Thanks! -- John J. Karcher devuser(a)alternateapproach.com

5 9

Roadmap 2021
by Norman Feske 19 Jan '21

19 Jan '21

Dear Genode community, the end of the strange year 2020 comes in sight. So now it is time to kick off our annual road-map discussion. I'll keep up with our tradition of reviewing the past 12 months from my personal perspective, dropping my ideas for the upcoming year, and inviting you to share your ideas and plans. Review of 2020 -------------- The overarching theme of our road map for 2020 was "Dwarfing the barrier of entry", which expressed the ambition to reach a wider audience. On that account, we identified four promising directions: First, making Sculpt OS palatable for a wider circle. Second, fostering the public perception of the high quality of Genode to reinforce the confidence of people who are sceptical towards novel operating-system technology. Third, lowering the barrier of entry by providing frictionless tooling. And fourth, publicly presenting use cases that prove the fitness and flexibility of Genode. These directions certainly did a good job of motivating the working topics of this year's four releases [1,2,3,4]. [1] https://genode.org/documentation/release-notes/20.02 [2] https://genode.org/documentation/release-notes/20.05 [3] https://genode.org/documentation/release-notes/20.08 [4] https://genode.org/documentation/release-notes/20.11 The UI improvements of Sculpt OS in version 20.02 largely eliminated the need to use the command line, as shown in my live demo [5]. But the work on the user-visible side of Sculpt has admittedly dried up a bit since spring time. Software quality has been a continuous topic. Personally, I dedicated a lot of energy to the improvement and consolidation of our POSIX support (Noux vs. libc) and the related infrastructure like the VFS server. [5] https://www.youtube.com/watch?v=vmgWgzeKAjU That said, despite the many technical advances, the stated soft goal of reaching a broader audience remains fairly distant. Genode has not seen a significantly wider adoption by the open-source community at large compared to one year ago. On the other hand, regarding our stated commitment to 64-bit ARM hardware, in particular supporting the NXP i.MX8 SoC, there is a strong sense of accomplishment, which makes me proud. The depth and breadth of this line of work has been fantastic. I'm speaking of 64-bit multi-core virtualization, HDMI, touch input, OLED, networking, LTE, USB, clock and power management, VirtIO, up to running Sculpt OS on this platform. It is a huge success story on a technical account. Regarding our reach to a broader community, we are super excited about the prospect of combining Genode with the MNT-Reform laptop that is based on the i.MX8 SoC. When speaking of i.MX8 one year ago, I also had the Librem5 in mind - envisioning Genode on a smart-phone form factor. But that hope remained abstract as we did not succeed to establish a correspondence with the makers of the Librem5. The vision of a Genode-based smart phone, however, has become stronger than ever (see below). While reading the paragraphs above, you may sense my ambiguous feelings about the past year's road map. I think we missed the stated goal. I also think that we excelled at technological progress. For us developers, the road map serves primarily as orientation for our technical work. But since the past year's goal of increasing adoption hasn't been a technical one, no level of technical excellence will magically bring us there. So the goal was a bit delusionally to begin with. Let us lift this pressure for the next year and concentrate on the technical level. My personal ambitions for 2021 ------------------------------ * By the end of the year, I want to use a Genode-based mobile phone, replacing my current Nokia 3720. I'll focus on the _Pinephone_. In fact, I have already taken the first baby steps and will continue to thoroughly document this line of work at https://genodians.org. * I see plenty of opportunities for optimization throughout Genode and would like to make _optimization_ the motto of the year. The following ideas are spontaneously crossing my mind: - Profiling and tuning of Unix-like workloads, in particular by looking at file-system access patterns. - Fostering the batching of async I/O, e.g., increasing the chance for the batching of network packets. - Let our ARM tool chain use the hard-float calling convention. - Replace the allocator of our C runtime by jemalloc. - Reducing the overhead of our POSIX TLS mechanism. - Taking XML parsing off the critical path for the dynamic reconfiguration of init. - Removing indirections, in particular the old libc plugin interface. - Reducing the inflation of binaries by C++ templates. - Improving compilation times by reducing header interdependencies. - Merging core's CPU and PD service into one. * I'm convinced that we have to dramatically reduce the engineering effort needed to port device drivers from the Linux kernel to Genode. Backed by our practical DDE-Linux experience, a few ideas have formed in the back of my head. They want out. So I see my work with the Pinephone as a welcome opportunity for experimenting in this direction. What's your perspective? ------------------------ For drafting the road map of next year, I'm eagerly interested in the perspective of my fellow developers and of course users of Genode. How do you perceive the outcome of the year? What areas would you wish to concentrate on? Where do you see untapped potential of Genode? How do you envision Genode in December 2021? I would very much appreciate your input for forming a rough picture of next year. Of course, not all ideas will make it to the road map. Economic constraints and the willingness of pro-active participation play a major role. Regarding the timeline, I plan to announce the official road map for 2021 in mid of January. 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

19 44

VMM for arm64 / Error on booting in I.MX8MQ EVK
by fixed-term.christo.bita＠sojus-software.de 08 Jan '21

08 Jan '21

Hallo all together, I am working on a scenario that includes the Genode's VMM hosting a Linux VM. For the first test: a) I build a Linux VM after the instructions from https://genodians.org/ssumpf/2020-02-24-linux-vm . (https://genodians.org/ssumpf/2020-02-24-linux-vm) b) The Linux Image, initrd and the dtb binary are in (genode-dir)/build/arm_v8a/bin copied. c) Build the run/vmm_arm for KERNEL=hw BOARD=imx8q_evk d)Booted the uImage from var/run/vmm_arm The result is as following: ## Booting kernel from Legacy Image at 50000000 ... Image Name: Image Type: AArch64 Linux Kernel Image (gzip compressed) Data Size: 12335823 Bytes = 11.8 MiB Load Address: 40010000 Entry Point: 40010000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... kernel initialized ROM modules: ROM: [000000004025d000,000000004025e742) LICENSE.bitstream-vera ROM: [00000000404fb000,000000004050b9b7) README ROM: [0000000041153000,0000000041153006) VERSION ROM: [00000000401bf000,00000000401cf18c) Vera.ttf ROM: [00000000404b0000,00000000404bc048) VeraMono.ttf ROM: [0000000040d56000,0000000040d6bfb8) backdrop ROM: [0000000041a96000,0000000041b56800) bash-minimal.tar ROM: [0000000040d3c000,0000000040d3c05c) block_devices.report ROM: [0000000040d88000,0000000040e18360) bootstrap-hw-imx8q_evk.o ROM: [0000000041a08000,0000000041a24758) cached_fs_rom ROM: [0000000040d3d000,0000000040d558b8) chroot ROM: [0000000041d22000,0000000041d3a058) clipboard ............... 3038 MiB RAM and 64533 caps assigned to init [init] Warning: runtime assigned RAM (32G) exceeds available RAM (2845327784) [init] Error: RAM preservation exceeds available memory [init -> log_kernel] Error: ROM-session creation failed (ram_quota=6144, cap_quota=3, label="log") [init -> log_kernel] Error: Could not open ROM session for "log" [init -> log_kernel] Error: Uncaught exception of type 'Genode::Rom_connection::Rom_connection_failed' [init -> log_kernel] Warning: abort called - thread: ep [init -> config_fs] tar archive 'launcher.tar' local at 0x121000, size is 12288 .... [init -> report_fs] Warning: ram donation is 182700 but used RAM is 184320B, 'ro' [init -> report_fs] Warning: cap donation is 11 but used caps is 12, 'ro' [init -> report_fs_rom] /drivers/usb_active_config ROM file is missing [init -> report_fs_rom] /drivers/usb_active_config ROM file is missing [init -> report_fs_rom] /drivers/usb_active_config ROM file is missing [init -> report_fs_rom] /drivers/usb_active_config ROM file is missing I presume something went wrong during the initialization process. Where does the value of the assigned RAM comes from? Is the exceeded value of requested RAM that causes the scenario to fail? Best regards, Christo

2 1

mmap implementation for ANON mapping with desired address
by Alexander Tormasov 21 Dec '20

21 Dec '20

I am trying to implement not-yet supported (as mentioned by nfeske@ in mailing list) option for mmap() related to anonymous mapping with pre-defined (desired) address. Like libc function with desired address out_addr. void *Libc::Mem_alloc_impl::alloc_at(void *out_addr, size_t size) I use a couple of useful function in avl allocator. Anyway, I found that straight - forward implementation do not work because of allocation gaps filled together with main allocation. In particular, if we want to allocate e.g. 0x10000 from address 0x500000 then we typically allocate 0x13000 bytes, including ones for avl metadata/etc stored in the same space, and receive virtual address range used, e.g. 0x500000 - 0x513000: /* * Calculate block size of needed backing store. The block must hold the * requested 'size' with the requested alignment, a new Dataspace structure * and space for AVL-node slab blocks if the allocation above failed. * Finally, we align the size to a 4K page. */ size_t request_size = size + max((1 << align_log2), 1024) + Allocator_avl::slab_block_size() + sizeof(Dataspace); Software I used (golang runtime) sometimes try to expand previous allocation, e.g. it can request allocation of 0x8000 bytes before previous range, like 0x4f8000 - 0x500000. In that case I can’t perform the operation - because it will try to allocate 0xa000 bytes from desired address 0x4f8000 - and it obviously fail due to Range_conflict. So, I split allocation to 2 parts - one for this gap by standard alloc() and random placement and second one by my own alloc_at() with size exactly correspond to the requested one. Implementation available as a patch to 20.05 at https://github.com/tor-m6/genode/commit/78fc751bea8acc2b515e04bec9f3a883461… Problem I see here is a free operation: it just free the block with requested address, and do not touch others, gap-related blocks. For me it is not obvious that they need to be free, because in the code (e.g. by unmap()) I do not see explicit free of other allocated structures, in particular, dataspace extension or related block metadata. Question: should I make additional efforts to trace and delete something else - except what standard free does here: /* forward request to our local allocator */ _alloc.free(addr); Like for dataspace structure or address ranges for second «auxiliary» allocation? PS Another potential problem is a probability to overlap of first «random address» allocation with desired address. This happens with first attempt to implement allocator - it allocates address from desired range, and immediately put here 0x18 bytes of Dataspace structure, and then fail because requested address is already busy by this structure! Anyway, I consider such a probability relatively small with proposed approach and ignore it (may be I am wrong)

4 23

My roadmap
by Michael Grunditz 19 Dec '20

19 Dec '20

Hi everyone, I was reading the 2020 reflections on Genode. Here is my plans for 2021 related to Genode: 1) Make the RK3399 port complete which for example includes PineBook Pro. HDMI will be easy, and I think eDP will be as well. The question is if doing it with DDE-Linux or from scratch. The RK3399 port is really only a exercise for me , since we already is on our way with a native port of RISC OS. But I guess a port of Genode can be useful for others. 2) RISC OS kernel running on top of base-hw , big project: 2a) The RISC OS kernel is written in ARM assembler, I will attempt to bring it over to C. 2b) Replace HAL with Genode facilities. 2c) Write some kind of emulation layer. RISC OS uses SWI for everything and that will not work on 64bit. It will be important to be able to run 32bit programs. 2d) Bring up Genode on all future aarch64 systems! 3) Bring up Genode on A64... I guess it might have been done partly already. It is the SoC that PinePhone is built on. I have been in the team porting RISC OS to A64 , so I know a few things. The only thing we haven't done natively is graphics. The only doc for DE 2.0 is a register description (VERY large document). No appnotes which makes it close to impossible to do without looking at BSP. We used simplefb , that is , starting graphics in uboot and use the resulting framebuffer. NetBSD also does graphics this way. 4) Learn to use the DDE-Linux. I hope that 2021 will be healthier :) Best regards, Michael Grundiitz

2 1

update openssl port
by Duss Pirmin 17 Dec '20

17 Dec '20

Hi Genodians On December 08. 2020 the openssl project issued a security advisory (https://www.openssl.org/news/secadv/20201208.txt). I started looking into binging the latest version of openssl (1.1.1i) to Genode. I have a first version of the library that compiles on x86_64. When I started testing components I encountered the following things: - `wpa_supplicant` (wifi driver) compiles, but running it fails due to a symbol the dynamic linker can't find - `lighttpd` compiles, but running it fails due to a symbol the dynamic linker can't find - `libssh` doesn't compile (it looks, as it uses data structures that were moved to internal only in version 1.1.x of openssl) - `openvpn` (repo genode-world) doesn't compile (it looks, as it uses data structures that were moved to internal only in version 1.1.x of openssl) - `grpc` (repo genode-world) compiles with some warnings about using deprecated functions - `grpc_tls/client` and `grpc_tls/server` (repo genode-world) can be built I'm thinking about how to proceed with this. One way that I see, is to create a separate port (e.g. `openssl_1.1`) that provides the updated library. Then each component can choose to use the old or the new version of the library. When a component (or library) is updated, one can choose to switch to the new library if it is supported. In the long run the old version of openssl could then be removed once all users of it have switched. Do you agree with proceeding according to this plan or would you approach this differently? Best regards, Pirmin

4 3

vfs fifo pipe and file system session write
by Stefan Thöni 09 Dec '20

09 Dec '20

Hello Genodians We are still trying to introduce a named pipe for communication between libc components and pure genode components. Our vfs fifo pipe now works with multiple threads in the same process, but only when it's hosted in the vfs of that same component. As soon as we host it in separate vfs component it stalls randomly. Our analysis shows that the reason for this lies in the implementation of the file system session interface, where the write operation doesn't report back the number of bytes written but the receiving vfs component instead retries the write operation. This leads to a permanent blocking of the vfs component as no read operation can alleviate the full buffer of the fifo pipe. We think the only proper fix would be a change in the file system session to allow the write operation to report back the number of bytes written. Is there a specific reason to keep the write 'fire-and-forget', other than simplicity? 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 3

whether genode c++ support RTTI
by yadong.li 09 Dec '20

09 Dec '20

Hi， I am a newer， I have some question about genode about c++ RTTI My test command is “make -C build/x86_32 KERNEL=sel4 BOARD=pc run/demo”, my genode version is “19.02” I add “typeid”, compile warning “must inclue <typeinfo>”, but this must compile add “stdcxx” lib, If add stdcxx, they need “Libc::Component::construct”, it is conflict with “Component::construct” of genode How can I resolve it, or Is there some demo support c++RTTI ? Thank you very much

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users