users

users@lists.genode.org

2357 discussions

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

IRQ handling question
by Jilong Kuang 06 Jan '13

06 Jan '13

Hi, I was trying to test the basic IRQ handling in Genode. I simplified the code from os/src/drivers/input/ps2/irq_handler.h and ran it on both QEMU and real machine. However, neither keyboard nor mouse interrupts can be properly captured by my code. For keyboard (IRQ 1), it keeps triggering interrupt even when there is no key press. For mouse (IRQ 12), there is no interrupt at all. As the ps2_drv works fine in the demo app, I'm sure something is missing in my stand-alone code (or I need to include other modules?). I appreciate if anyone can point it out. I attached my code here for your reference. Best, Jilong =========================================================== class Irq_handler : Genode::Thread<4096> { private: Genode::Irq_connection _irq; int irq_num; public: Irq_handler(int irq_number) : _irq(irq_number) { irq_num=irq_number; start(); } void entry() { while (1) { _irq.wait_for_irq(); Genode::printf("received an IRQ %d!\n",irq_num); } } }; int main() { printf("Entered: test-irq\n"); Irq_handler ps2_mouse_irq(12); Irq_handler ps2_keyboard_irq(1); Genode::sleep_forever(); }

2 1

preventing double remove of Avl_node_base
by jaeyong yoo 05 Jan '13

05 Jan '13

Hello, Avl_node_base::remove function removes itself from the Avl_tree and leaves the _parent and _child[] variables as they are. Since someone could try to remove the same Avl_node_base twice by mistake, it results in the crash of Avl_tree datastructure. So, how about setting _parent and _child[] to NULL at Avl_node_base::remove and, at the entry of the remove function, if someone tries to remove twice, we could warn him. Best regards, Jaeyong

2 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users