users

users@lists.genode.org

2357 discussions

Ideas about interactive GUI
by Boris Mulder 15 Apr '17

15 Apr '17

Dear Genode Community, We have been brewing on the best way to implement an interactive menu interface. We would like to hear your opinions and ideas on this. Currently, only launcher provides this functionality. However, we had the following objectives in mind: - Decouple the menu state and the functionality. We think the menu should only be responsible for rendering the dialogs and registering input events. Whatever functionality is to be invoked based on this input should be delegated to other components. - Have a fully customizable menu. The model of what buttons and (nested) submenus exist should be configurable, and should be separated from the layout (such as how a button looks like) and from the current state (which menus are collapsed, etc). In order to shape this, we have the following ideas: - The configuration of the menu model can be specified in XML in its config, and be reconfigurable at runtime. Parts of this could be defined by other components as well. Examples of how this could look like is described in the attached xml file. - Events related to the menu either trigger menu actions (in which case the config dictates the proper response, such as showing or hiding a submenu) or trigger external actions. In the second case, the menu generates a report that for instance states a certain button has been clicked. Again, see the attachment. - Any (custom) component can read these reports and take certain actions. For example, in case programs are to be started with the menu, we can add an init component that takes its config from another rom module. A subsystem management component containing a more extensive state model would read the events from the menu, change init's config based on this, and monitor the state of started subsystems and perhaps add extra context menus for these subsystems. Another example is a shutdown button that talks to a component that can write the system state, and which could show a dialog with the options to power off or reset a systems. Perhaps it can try to gracefully stop running programs with disk state (such as virtualbox) by talking with the subsystem manager as explained above. In any case, the menu should be able to support any functionality by providing a generic interface to components such as the examples above. - The layout of the menu can be specified in the config as well, perhaps using (a subset of) CSS, or as it is now, with the styles database that contains pictures for each element. (buttons, bars, etc.) While looking at ways to implement this, we also encountered the following problems: -As it is currently with launcher, a lot of subsystem functionality is intertwined with the interactive menu. This makes implementing such a modification a bit more difficult than replacing the subsystem management part with a reporting part. One of the issues we face is that showing and hiding windows of other components is done through the session_control function in the nitpicker session interface, but this is limited to the session of the components and its children. Children of an init component therefore cannot be affected. One way to fix this is to add a policy in the window manager or nitpicker that allows the menu or some other component to execute session_control on certain or all sessions. Implementing session_control functionality in init itself does not look like a clean solution. Another issue is that init does not keep track of exited children. Launcher neatly closes the corresponding menu entries by installing a signal when the child exits, but init does not have such functionality now. Perhaps init could be modified such that it generates a report when a child exits? For now, if we would quit a child with another method than through the menu, we have no way of knowing if a child exited. I'd very much like to hear your comments on these ideas and on the best way to realize it (perhaps together), and for instance how you think we could resolve the above issues. -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)

2 1

Problem with make run/demo & run/hellofor fiasco.oc based build
by Shahbaz khan 14 Apr '17

14 Apr '17

Dear list, I have started working with Genode, while I am interested in foc based development and it seems the Genode efforts also prefer foc as I have been trying run/demo for builds. I am facing a few problems. Some that makes sense as a developer, while some are new to me and definitely need some hints to move forward. I have encountered the following errors: x86_64 (run/demo & run/hello):- Error: target 'core' does not exist. I was not able to figure out how to enable build core but it should have been there by default like other Genode builds. pba9 (run/demo):- The mouse pointer does not work. pba9 (run/hello):- [init] Error: Uncaught exception of type 'Genode::Parent::Service_denied' linux (run/hello):- [init] Error: Uncaught exception of type 'Genode::Parent::Service_denied' Does the uncaught exception mean that the capability list is not configured properly? I am onto figuring out the build issue of core till your replies. Regards, Shahbaz Khan R&D Engineer, IM|Sciences

3 4

Socket fs
by Boris Mulder 13 Apr '17

13 Apr '17

Hi all, I've managed to port one of our existing network applications to use the socket fs from 17.02 now, starting from the echo_udp scenario and got it working. It looks a lot better now. Following this, we would like to share our findings about the socket fs so far: 1. In the release notes you describe the support for async file I/O. However, it seems that while asynchronous I/O works now, synchronous I/O is no longer possible. When I remove the select() call in the echo scenario, the call to recvfrom() will fail saying the socket is not connected (even though it is an UDP socket and should not have the notion of connections at all). Of course this means it is not posix compatible; the intended behaviour is to block until data becomes available. 2. Currently there are two ways an application can use tcp/ip sockets from the lxip stack: By using libc sockets, and by directly opening a file system session and writing to the right socket files. For any new Genode application that does not already depend on libc, the first way means you unnecessarily add the entirety of libc to your component. So the second way seems preferred. However, when programming an application using a file system session directly adds a lot of code with many open()s, read()s and write()s that could be abbreviated into single calls such as connect() and recv(). Have you thought of providing a more convenient API (such an object-oriented Socket class that hides the vfs calls from the application programmer)? Or do you consider using the fs session interface to be better? If so, why? -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)

3 3

infradead.org seems to be down
by Johannes Kliemann 11 Apr '17

11 Apr '17

Hi, while trying to build Genode with dde_linux I noticed that the connection to infradead.org timed out, so I'm not able to retrieve https://www.infradead.org/~tgr/libnl/files/libnl-3.2.25.tar.gz Is there any other source for this file? JK

4 7

Intel fb debug output
by Johannes Kliemann 10 Apr '17

10 Apr '17

Hi, I want to enable the debug output in the Intel framebuffer (to see messages printed by DRM_DEBUG_KMS). This is usually done by adding the boot parameter `drm.debug=0xe`. How would I enable this in Genode with Nova? JK

3 3

hello component doesn't run on foc_x86_32
by john stokes 05 Apr '17

05 Apr '17

hello Genodians , when i run the run script situated in lab for hello world then it runs fine on the linux_x86 but when i run it over foc_x86_32 then it shows this error : Error: No run script for hello make: *** [run/hello] Error 255 although i have added the custom repository in the etc/build.conf file and i have also created the run script named hello.run in the lab/run directory the same thing is happening with the hello_tutorial component also.please provide solution thanks in advace.

2 1

Timers
by christian schulte 04 Apr '17

04 Apr '17

Hi I am running Genode VMM demo on i.mx53 QSB. I wanted to configure the secure world or tz_vmm to switch to the normal world periodically using timer driver. It would be great if you could give me a hint how to do that. I think the board supports three timers (EPIT, GPT and watchdog). Which timer is accessed and used by the guest OS (Linux) and which one is not. How to protect the Genode timer driver as the normal world or Linux may interfere with it? Thanks a lot! Best regards, Christian

2 1

noux_bash + gcc
by Humblenoob 03 Apr '17

03 Apr '17

Hello! I'm relatively new to genode and my knowledge is poor, but I'm very fascinated by genode and microkernels in general. I hope to learn very much in the next several years. I've been able to build several working iso's from run scripts on both NOVA and seL4 with varying levels of success, which is very exciting! However, I'm not yet experienced or skilled enough to create my own custom scripts. My ideal system that I would like to create in the meantime would be noux_bash with gcc, g++, and make. How would I suppliment the existing noux_bash.run script to include these packages?

2 1

[GSoC] UEFI framebuffer task
by Philipp Kerling 31 Mar '17

31 Mar '17

Hi, I'm interested in participating in the Genode project as GSoC student, specifically the UEFI framebuffer task, so I am writing to you to briefly introduce myself and discuss the project idea. I am currently a student of Computer Engineering (MSc) at Ilmenau University of Technology in Germany in my second master semester. I've chosen computer engineering over computer science out of interest for low- level topics, which I think fits nicely with Genode. I worked on a toy x86 operating system with a friend some years ago, which was a good learning experience. It naturally did not go very far, but it did at least have basic multitasking and virtual memory :-) So, about the UEFI framebuffer proposal: Is the overall goal to have Genode/Nova running as bare UEFI application (without any OS Loader) or to have it loaded by GRUB (or similar) but not rely on outdated BIOS features (such as VBE) any more? Or support both like e.g. the Linux kernel does? This heavily influences the options available for framebuffer output, since the UEFI GOP (Graphics Output Protocol) that I assume you are referring to as one of the alternative/modern ways to access the framebuffer is only available as UEFI boot service. When being booted from an OS loader, usually only UEFI run-time services are available. In that case, the OS loader has to convey some information (mainly memory address, width/stride, height, depth) about the linear GOP framebuffer that the loader (or the firmware, for that matter) initialized to the kernel. multiboot2 does this for example with the framebuffer boot info tag. So to use this it would be sufficient to write a generic framebuffer driver operating on that information that is not specific to UEFI at all. It could probably also use the VBE framebuffer provided the OS loader initialized it. The "problem" with this is that it is probably not enough work to justify a 3-month GSoC proposal. I hope that the questions at least touch the right topics but do feel free to say so if you had something different in mind altogether. Best regards, Philipp

3 12

GSoC 2017 Consideration - Qemu
by Aaron 30 Mar '17

30 Mar '17

Hello, My name is Aaron. I am writing this letter because I would like to enter my name consideration in your [possible specificity] project. I did not participate in the pre-application phase, which I know places me at a disadvantage, and as a result I am sending this email to probe your interest. Your organization's participation in the Summer of Code is somewhat serendipitous for me. I had previously been communicating with the Qemu organization about the possibility of porting their software to additional platforms, but they were not receptive (possibly even planning to remove platform support). Porting qemu, is exactly what I've been wanting to do. I've also read through some of your mailing lists and I don't believe that anyone else is taking this task on. With all of that said: are you willing to accept new candidates, or are you only selecting from those that have already communicated? Thank you for any thoughts you might have, Aaron Hudson P.S. I made the mistake of emailing the main gsoc@...489..., which has only exacerbated the issue. The message above was the original message sent to that mailing list.

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