users November 2015

users@lists.genode.org

25 participants
23 discussions

QEMU instead of VirtualBox
by Jookia 09 Nov '15

09 Nov '15

Hey there, Given VirtualBox requires nonfree dependencies to be built, would it be worth having a port of QEMU running on Genode instead? How hard would it be to set this up? Cheers, Jookia.

1 0

Nitpicker changes
by Norman Feske 05 Nov '15

05 Nov '15

Hello, with the incorporation of my recent work on issue #1690 [1] into the master branch, the use and configuration of the nitpicker GUI server has changed. [1] https://github.com/genodelabs/genode/issues/1690 Up to now, nitpicker used to handle the so-called X-ray mode internally. When activated by the user by pressing a configurable key, this mode tinted all views with domain colors and added labeling information to all views. It was meant to assist the user with uncovering Trojan Horses. However, the built-in policy started to stand in our way when implementing advanced scenarios like Turmvilla [2]. Here, we want to be more flexible with how the X-ray mode is activated, and how it affects the behavior of the user interface. For example, the delivery of hovering motion events to unfocused sessions, the ability to change the input focus by clicking on a unfocused view, the suppression of the labeling for trusted parts of the GUI. Building-in all those "features" into nitpicker would ultimately increase its complexity, and still fail to cover all thinkable use cases. To avoid that, I removed the notion of the X-ray mode altogether but added all the various aspects of the policy as explicit attributes of nitpicker's domain configuration. The idea is that the notion of the X-ray mode is provided by a separate component (xray_trigger), which reconfigures nitpicker each time when the X-ray mode is toggled. The X-ray trigger component contains the policy of when the X-ray mode is activated. E.g., by interpreting certain global keys. It simply produces an X-ray report that tells whether X-ray is active or not. The reconfiguration of nitpicker is done by a separate component that takes the information of the X-ray report and generates a nitpicker configuration. To avoid this component to be nitpicker-specific, I came up with a generic 'rom_filter', which is able to generate a ROM module with arbitrary XML, depending on other ROM modules, like the X-ray report. The output of the ROM filter is fed to nitpicker as configuration. Granted, to achieve the original effect as present in the demo.run script, the scenario becomes more complicated because we have to start the xray_trigger and rom_filter in addition to nitpicker. However, we gain a lot of flexibility that can now be expressed by the means of combining and configuring those components. To see the interplay of those components to emulate the original behavior, please have a look at the os/run/demo.run script. Most other run scripts use nitpicker solely as an output facility. Here, the X-ray mode is actually unimportant and it suffices to set up the nitpicker configuration in a way that allows for basic interactions. For example, the following configuration can be used as a template: <config> <domain name="pointer" layer="1" content="client" label="no" origin="pointer" /> <domain name="default" layer="2" content="client" label="no" hover="always" focus="click" /> <policy label="pointer" domain="pointer"/> <policy label="" domain="default"/> </config> It assigns the pointer to its dedicated domain, using the pointer position of the origin of its coordinate space. All regular clients end up in the "default" domain, their content is presented as is (not tinted) without any labeling, motion events are delivered to the clients whether they are focused or not, and a client can be focused by clicking onto one of its views. As for a more sophisticated example, I have incorporated the new concept into my Turmvilla branch [2] where not only nitpicker but also the window decorator dynamically responds to the X-ray mode. Here, X-ray is activated whenever the pointer hovers a window decoration, which illustrates quite well the flexibility of the new approach. [2] https://github.com/genodelabs/genode/issues/1552 Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Cache lock-down on Pandaboard.
by Daniel Sobański 04 Nov '15

04 Nov '15

Hi there, Is there a way to lock L2 cache on Pandaboard ES with running Ubuntu there? TRM says that it is possible, but I don't know it feasible on Pandaboard. I've tried to compile kernel object and set there bits in Auxiliary Control Register using cp15, but it's RO I suppose, because I cannot write there. CPSR says I am in a Privilige mode, but i guess that's a non-secure Privilige mode? How to use that PL310 cache controller to do that? Do I need to use TrustZone somehow? When compile SMC #1 instruction using asm volatile(...) when compiling natively on Panda, when trying to taskset this Panda is not responding. Cheers,

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users November 2015