users December 2012

users@lists.genode.org

14 participants
16 discussions

About stack pointers in thread_base
by jaeyong yoo 07 Jan '13

07 Jan '13

Hello, While I was browsing source code, I found two confusing variables: At genode/base/include/base/thread.h Thread_base::Context { long stack[]; addr_t stack_base; } Although, they are commented a bit, it is hard to understand what are they doing and what's the difference. Could you tell me about them more? Best, Jaeyong

2 3

Capability mapping
by Daniel Waddington 07 Jan '13

07 Jan '13

Hi, I'd like to better understand the capability mapping support in Genode. Is there a generalized mechanism (beyond RPC endpoint mapping) for a parent to map capabilities (e.g., Dataspace) between two child processes? Can a process (e.g., client) map a capability into another capability? I am wondering how the packet_stream interface establishes shared memory e.g., for channels. I guess I am looking for something equivalent to L4Re l4re_ns_query_to_srv <http://os.inf.tu-dresden.de/L4Re/doc/group__api__l4re__c__ns.html#ga5069ab9…> and l4re_ns_query_to_srv <http://os.inf.tu-dresden.de/L4Re/doc/group__api__l4re__c__ns.html#ga5069ab9…> APIs. Sorry for the newbie questions. Daniel

3 5

Question regarding Rm_client::unmap in Fiasco.OC
by jaeyong yoo 02 Jan '13

02 Jan '13

Hello, While I was browsing, I found that, in function Rm_session_client::detach(), there is a part that looping over Rm_client and unmap it: for (Rm_client *rc = _clients.first(); rc; rc = rc->List<Rm_client>::Element::next()) { /* * XXX Unmapping managed dataspaces on kernels, which take a core- * local virtual address as unmap argument is not supported yet. * This is the case for Fiasco, Pistachio, and NOVA. On those * kernels, the unmap operation must be issued for each leaf * dataspace the managed dataspace is composed of. For kernels with * support for directed unmap (OKL4 or Codezero), unmap can be * simply applied for the contiguous virtual address region in the * client. */ if (!platform()->supports_direct_unmap() && dsc->is_managed() && dsc->core_local_addr() == 0) { PWRN("unmapping of managed dataspaces not yet supported"); break; } rc->unmap(dsc->core_local_addr() + region->offset(), // <=== this part region->base(), region->size()); } The implementation of Rm_client::unmap is the following: void Rm_client::unmap(addr_t core_local_base, addr_t virt_base, size_t size) { // TODO unmap it only from target space unmap_local(core_local_base, size >> get_page_size_log2()); } In the above function, since it is not using any member variables of Rm_client, when Rm_session_client::detach() calls multiple of Rm_client::unmap it is just calling the same function of "unmap_local" with the same parameters. It results in calling l4_task_unmap multiple times with the same parameters. I'm just concern that this may not cause anything harmful. Best, Jaeyong

2 1

Genode Page-Fault Handling and IRQ architecture
by Daniel Waddington 21 Dec '12

21 Dec '12

Hi, W.r.t. Fiasco.OC ... Can someone give a brief explanation of the Genode PF and IRQ handling architecture. I'd like to understand the path from the kernel to the general or custom handler. My (previous) understanding is that PFs are managed through the core process (which is single threaded running on core0) and farmed off (via signals) to a custom handler if attached. Is there a way to handle a PF without an interaction with 'core'? (assuming let's say I have the memory and the mapping answer). Likewise with IRQ handling, can someone explain the path from an IRQ firing in the kernel to the app-level handler? Daniel

2 6

Demo: Diverging testnit window
by Martin Stein 19 Dec '12

19 Dec '12

When moving a testnit window a little faster in the demo i observe that the window diverges from its original position relative to the mouse pointer. The behavior blows up when moving more and more. This is at least true for the hw platforms in qemu and real and for nova_x86_32 in qemu. It does not occur on e.g. the launchpad. Should this be an issue?

1 0

Transfer data from server to client via Rpc_in_buf troubles
by Nikolay Golikov 19 Dec '12

19 Dec '12

Hi all, Now I working on i2c driver for i.mx53 platform. In i2c_session interface I using Rpc_in_buf for transfer data between driver and client: enum { MAX_BUFFER_SIZE = 256 }; typedef Genode::Rpc_in_buffer<MAX_BUFFER_SIZE> Byte_array; virtual bool read(Genode::uint8_t address, Genode::uint8_t register, Byte_array &out) = 0; virtual bool write(Genode::uint8_t address, Genode::uint8_t register, Byte_array const &in) = 0; GENODE_RPC(Rpc_read, bool, read, Genode::uint8_t, Genode::uint8_t, Byte_array &); GENODE_RPC(Rpc_write, bool, write, Genode::uint8_t, Genode::uint8_t, Byte_array const &); Write function transfer data to driver normally, but after read rpc call on client side the buffer content does not change.

2 1

some problem in linux_syscalls.h
by 서재권 18 Dec '12

18 Dec '12

2 1

제목없음
by 서재권 18 Dec '12

18 Dec '12

1 0

Boot method declaration
by Martin Stein 18 Dec '12

18 Dec '12

By now when doing a build there are two ways of defining the boot method. In 'base-mb' one writes 'RUN_OPT="--target jtag" make demo' or 'RUN_OPT="--target qemu" make demo' while qemu is set by default. At least in base-hw with imx53 one must enrich the SPECS e.g. in etc/specs.mk by the 'uboot' spec to get an appropriate Uboot image. Are there pros or cons for one of these methods, because i would prefer to use only one them.

3 4

Cpu session interface num_cpus
by Daniel Waddington 18 Dec '12

18 Dec '12

Hi, I am trying to use num_cpus as described in release notes 12-11 on Fiasco.OC, but it's not there - it calls the virtual implementation on platform_generic.h returning 1. I am using GIT branch master - should I be using something else? Daniel

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users December 2012