users September 2014

users@lists.genode.org

24 participants
31 discussions

Fw: Fw: Re: Some questions about performance optimization related toGUIframework on Genode
by 王硕 09 Sep '14

09 Sep '14

Hello Norman and all, Sorry for my disturbance. I leave out the instruction to run the verify.iso in qemu. To run verify.iso, you should execute the command $ qemu -m 1024 -serial mon:stdio -smp 2,cores=2 -net nic,model=e1000 -net user verify.iso‍ in terminal. Shuo Wang, University of Chinese Academy of Sciences. ------------------ Orignial ------------------ <kloisiie@...236...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Fw：Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, Here is a .iso file of the VSOS system. If you can't build and run from the source code, you can try this: ‍http://pan.baidu.com/s/1hq8Aews‍ Thank you for you help. Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, I'm sorry for my carelessness. L4_UTCB_USER_ID_OFFSET is defined in \base-foc\contrib\l4\pkg\l4sys\include\ARCH-x86\utcb.h as L4_UTCB_USER_ID_OFFSET = 62 * sizeof(l4_umword_t), Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "norman.feske";<norman.feske@...1...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Shuo Wang, > In Genode, it takes approximately 3 seconds for qt_launchpad to launch, > and more than 1 seconds for other apps to launch. This is too slow, so > my task is to reduce the launch time of qt_launchpad and apps. But I > don't know what the reason of the low performance is. So I turn to you > for some advice. I cannot reproduce this observation. Please give the qt5 run script of Genode 14.08 a try. When started on real hardware (not on Qemu!), Qt5 applications, including the qt_launchpad, open up instantly. I guess that you performed your measurement either on Qemu, or using your group's branch of Genode. Speaking of this branch, I still could not get it running (see my last email about the missing definition of L4_UTCB_USER_ID_OFFSET). However, by quickly skimming over it, I have seen modifications that may impede performance quite significantly. E.g., the following addition in the RPC server code: https://github.com/kloisiie/vsos/blob/master/base/include/base/rpc_server.h… Not knowing the reasoning behind this code, I suspect that it goes against the grain of Genode in several ways. * It seems to introduce the notion of global IDs, which Genode tries to avoid to counter problems like "ambient authority". * With my limited understanding of your changes, it looks like your group implemented a classical ACL-policy mechanism right into the heart of Genode. In my opinion, this approach contradicts with the Genode's capability-based access-control model. I would love to know the rationale behind this line of work and discuss possible alternative solutions that are coherent with Genode's design. * The code path is performance-critical, yet it performs slow string compare operations and RPC calls. * It mixes different levels of abstractions. 'rpc_server.h' contains the low-level message-dispatching mechanism whereas the notions of objects, sessions, and connections are introduced on top of that. By creating a "Monitor_connection" object within the low-level code path, the low-level code becomes reliant on higher-level abstractions that are built on top of the low-level code. Such circular dependencies are not good. * It is specific to one particular kernel. Given the huge amout of changes in your branch, there might be a good chance that other performance-critical parts were changed for the worse, too. To see whether the performance problems are actually on Genode's account or stemming from the changes of your group, please check that the problems can be reproduced on the unmodified version of Genode. Best regards 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 ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ genode-main mailing list genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

1 0

The added mechanisms in VSOS.
by 王硕 09 Sep '14

09 Sep '14

Hello Norman, Our team developed some apps to present BLP and Biba access-control model. All of these apps can be started in qt_launchpad. In order to simulate a login process, they used several "Connections" (just like Monitor__Connection) to "jump" from the login windows to qt_launchpad (or reversely). Secure attention key was also implemented like this in void handle_event() in ps2_keyboard.h. (https://github.com/kloisiie/vsos/blob/ff16f26ffe37a70fded8d02277e67a0c29e6e…) For example, in main.cpp in qt_launchpad: int main(int argc, char *argv[]) { ... ... ‍ Timer::Connection loginwait; while(true){ if(loginfinished) break; else { loginwait.msleep(1500); } } ... ... ... launchpad->show(); ... ... ... }‍‍ the while(true) loop will be broken if and only if the login app (in qt4/src/apps/verify) validate the username and password and change the loginfinished‍ flag to TURE. Then the login windows hides and qt_launchpad will continue executing and show the window. The default username (the left textbox/QLineEdit in the first line of login app) and passwords (the textbox in the second line) are admin and helloos5, and the default login level (following BLP model, the right ComboBox in the first line) is 2. The audit and access-control mechanism was implemented in /base/include/monitor_session. https://github.com/kloisiie/vsos/tree/master/base/include/monitor_session‍ https://github.com/kloisiie/vsos/blob/master/base/src/core/include/monitor_… Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original ------------------ <kloisiie@...236...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Fw：Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, Here is a .iso file of the VSOS system. If you can't build and run from the source code, you can try this: ‍http://pan.baidu.com/s/1hq8Aews‍ Thank you for you help. Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, I'm sorry for my carelessness. L4_UTCB_USER_ID_OFFSET is defined in \base-foc\contrib\l4\pkg\l4sys\include\ARCH-x86\utcb.h as L4_UTCB_USER_ID_OFFSET = 62 * sizeof(l4_umword_t), Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "norman.feske";<norman.feske@...1...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Shuo Wang, > In Genode, it takes approximately 3 seconds for qt_launchpad to launch, > and more than 1 seconds for other apps to launch. This is too slow, so > my task is to reduce the launch time of qt_launchpad and apps. But I > don't know what the reason of the low performance is. So I turn to you > for some advice. I cannot reproduce this observation. Please give the qt5 run script of Genode 14.08 a try. When started on real hardware (not on Qemu!), Qt5 applications, including the qt_launchpad, open up instantly. I guess that you performed your measurement either on Qemu, or using your group's branch of Genode. Speaking of this branch, I still could not get it running (see my last email about the missing definition of L4_UTCB_USER_ID_OFFSET). However, by quickly skimming over it, I have seen modifications that may impede performance quite significantly. E.g., the following addition in the RPC server code: https://github.com/kloisiie/vsos/blob/master/base/include/base/rpc_server.h… Not knowing the reasoning behind this code, I suspect that it goes against the grain of Genode in several ways. * It seems to introduce the notion of global IDs, which Genode tries to avoid to counter problems like "ambient authority". * With my limited understanding of your changes, it looks like your group implemented a classical ACL-policy mechanism right into the heart of Genode. In my opinion, this approach contradicts with the Genode's capability-based access-control model. I would love to know the rationale behind this line of work and discuss possible alternative solutions that are coherent with Genode's design. * The code path is performance-critical, yet it performs slow string compare operations and RPC calls. * It mixes different levels of abstractions. 'rpc_server.h' contains the low-level message-dispatching mechanism whereas the notions of objects, sessions, and connections are introduced on top of that. By creating a "Monitor_connection" object within the low-level code path, the low-level code becomes reliant on higher-level abstractions that are built on top of the low-level code. Such circular dependencies are not good. * It is specific to one particular kernel. Given the huge amout of changes in your branch, there might be a good chance that other performance-critical parts were changed for the worse, too. To see whether the performance problems are actually on Genode's account or stemming from the changes of your group, please check that the problems can be reproduced on the unmodified version of Genode. Best regards 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 ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ genode-main mailing list genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

1 0

Fw：Re: Some questions about performance optimization related toGUIframework on Genode
by 王硕 09 Sep '14

09 Sep '14

Hello Norman, Here is a .iso file of the VSOS system. If you can't build and run from the source code, you can try this: ‍http://pan.baidu.com/s/1hq8Aews‍ Thank you for you help. Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, I'm sorry for my carelessness. L4_UTCB_USER_ID_OFFSET is defined in \base-foc\contrib\l4\pkg\l4sys\include\ARCH-x86\utcb.h as L4_UTCB_USER_ID_OFFSET = 62 * sizeof(l4_umword_t), Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "norman.feske";<norman.feske@...1...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Shuo Wang, > In Genode, it takes approximately 3 seconds for qt_launchpad to launch, > and more than 1 seconds for other apps to launch. This is too slow, so > my task is to reduce the launch time of qt_launchpad and apps. But I > don't know what the reason of the low performance is. So I turn to you > for some advice. I cannot reproduce this observation. Please give the qt5 run script of Genode 14.08 a try. When started on real hardware (not on Qemu!), Qt5 applications, including the qt_launchpad, open up instantly. I guess that you performed your measurement either on Qemu, or using your group's branch of Genode. Speaking of this branch, I still could not get it running (see my last email about the missing definition of L4_UTCB_USER_ID_OFFSET). However, by quickly skimming over it, I have seen modifications that may impede performance quite significantly. E.g., the following addition in the RPC server code: https://github.com/kloisiie/vsos/blob/master/base/include/base/rpc_server.h… Not knowing the reasoning behind this code, I suspect that it goes against the grain of Genode in several ways. * It seems to introduce the notion of global IDs, which Genode tries to avoid to counter problems like "ambient authority". * With my limited understanding of your changes, it looks like your group implemented a classical ACL-policy mechanism right into the heart of Genode. In my opinion, this approach contradicts with the Genode's capability-based access-control model. I would love to know the rationale behind this line of work and discuss possible alternative solutions that are coherent with Genode's design. * The code path is performance-critical, yet it performs slow string compare operations and RPC calls. * It mixes different levels of abstractions. 'rpc_server.h' contains the low-level message-dispatching mechanism whereas the notions of objects, sessions, and connections are introduced on top of that. By creating a "Monitor_connection" object within the low-level code path, the low-level code becomes reliant on higher-level abstractions that are built on top of the low-level code. Such circular dependencies are not good. * It is specific to one particular kernel. Given the huge amout of changes in your branch, there might be a good chance that other performance-critical parts were changed for the worse, too. To see whether the performance problems are actually on Genode's account or stemming from the changes of your group, please check that the problems can be reproduced on the unmodified version of Genode. Best regards 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 ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ genode-main mailing list genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

1 0

Translation Table Memory Attribute bits
by Bob Stewart 08 Sep '14

08 Sep '14

I've never been able to get 14.05 or 14.08 working on my AM335X processor, which is not a big deal as 14.02 has everything I need for the applications I'm using that processor for. But out of curiosity: The issue on 14.08 may revolve around memory access bit rights in TLB table entries. To get 14.08 to initialize the kernel properly the memory access bits have to be set as Tex = 0, B = 1, and C = 0. These setting seem correct for a shared Device according to the Arm v7 ref manual. With those settings in place, the kernel initializes properly and eventually init runs. During the kernel initialization process Core_pd is called and translations are created for the program image (which starts at 0x81000000) and the core-only io memory regions. The translation table entries for the program image are of section size plus a small page so two entries are inserted in the translation table. The access bits and permission bits for the section entry are correct with the possible exception of the C bit, which in 14.08 appears never to be set and I wondered why that was, when it is used in 14.02. Once the init thread runs, any reference to the translation table entry for the program image, the section entry mentioned above cause a mmu exception as the following partial debug output shows: ... start thread 3 'entrypoint' in program 1 'core' on processor 0/1 start thread 4 'signal' in program 1 'core' on processor 0/1 start thread 5 'pager_activation' in program 1 'core' on processor 0/1 int main(): --- start init --- int main(): transferred 507 MB to init start thread 6 'init' in program 1 'core' on processor 0/1 thread id is 0x7 start thread 7 'init' in program 2 'init' on processor 0/1 void Kernel::Thread::_mmu_exception(): f_addr 0x81000000 f_writes 0x0 f_pd 0x813ed088 f_signal 0x7f label init int main(): --- init created, waiting for exit condition --- void Kernel::Thread::_mmu_exception(): f_addr 0x81045f60 f_writes 0x1 f_pd 0x813ed088 f_signal 0x7f label init void Kernel::Thread::_mmu_exception(): f_addr 0x8102dab8 f_writes 0x0 f_pd 0x813ed088 f_signal 0x7f label init ... Setting the C bit as it was set in 14.02 makes no difference, which I thought it would and it should be affecting caching behavior. Any thoughts on this behavoir? Thanks, Bob

3 10

Malloc / free ansd rump_fs ->Slab-backend exhausted
by unknown＠example.com 05 Sep '14

05 Sep '14

Hi, i try to open a file. I used the following code: //malloc char * buffer = (char*) Genode::env()->heap()->alloc(sizeof(char)*lSize); FILE* pFile = fopen(fileName, "rb"); size_t result = fread (buffer,1,lSize,pFile); fclose (pFile); //free (buffer); env()->heap()->free(buffer, 0); The code seems to work if the file is quite small. I try thre same with a file of size 128 MB. I have given rump_fs a quite large quota of 520M [Quota exceeded! amount=69632, size=8192, consumed=65536[0m [Could not allocate metadata[0m [init -> rump_fs] [upgrading quota donation for Env::RAM (8192 bytes)[0m [Quota exceeded! amount=77824, size=8192, consumed=73728[0m [Could not allocate metadata[0m [init -> rump_fs] [upgrading quota donation for Env::RAM (8192 bytes)[0m [init -> rump_fs] [Slab-backend exhausted! And from this point onwards only Slab-backend exhausted messages are shown. Is there some max size for ram quotas? Best regards, Wolfgang

3 9

fyi - make prepare on 14.08 - hashes
by D X 03 Sep '14

03 Sep '14

Hi, just an fyi - I created a new directory to git 14.08, and I got the following hash errors on prepare: on ports -> virtualbox ----------- test -n " http://download.virtualbox.org/virtualbox/4.2.24/VirtualBox-4.2.24.tar.bz2" ||\ (echo -e "Error: Undefined URL for VirtualBox-4.2.24.tar.bz2"; false); name=VirtualBox-4.2.24.tar.bz2;\ (test -f $name || echo -e "\033[00;33mvirtualbox \033[0m""download " http://download.virtualbox.org/virtualbox/4.2.24/VirtualBox-4.2.24.tar.bz2); \ (test -f $name || wget --quiet http://download.virtualbox.org/virtualbox/4.2.24/VirtualBox-4.2.24.tar.bz2 -O $name); \ (echo -e "4685a898fb426ae59081a3b3adf3f5b8c5cfd34e VirtualBox-4.2.24.tar.bz2" |\ sha1sum -c > /dev/null 2> /dev/null) || \ (echo -e Error: Hash sum check for virtualbox failed; false) Error: Hash sum check for virtualbox failed make[2]: *** [virtualbox.file] Error 1 on libports -> libdrm, mesa ---------------- test -n "http://dri.freedesktop.org/libdrm/libdrm-2.4.21.tar.bz2" ||\ (echo -e "Error: Undefined URL for libdrm-2.4.21.tar.bz2"; false); name=libdrm-2.4.21.tar.bz2;\ (test -f $name || echo -e "\033[00;33mlibdrm \033[0m""download " http://dri.freedesktop.org/libdrm/libdrm-2.4.21.tar.bz2); \ (test -f $name || wget --quiet http://dri.freedesktop.org/libdrm/libdrm-2.4.21.tar.bz2 -O $name); \ (echo -e "be7754008424a12e01ab0f0da3deb8de13ad2f0c libdrm-2.4.21.tar.bz2" |\ sha1sum -c > /dev/null 2> /dev/null) || \ (echo -e Error: Hash sum check for libdrm failed; false) Error: Hash sum check for libdrm failed make[2]: *** [libdrm.file] Error 1 test -n " ftp://ftp.freedesktop.org/pub/mesa/older-versions/7.x/7.8.1/MesaLib-7.8.1.t…" ||\ (echo -e "Error: Undefined URL for MesaLib-7.8.1.tar.gz"; false); name=MesaLib-7.8.1.tar.gz;\ (test -f $name || echo -e "\033[00;33mmesa \033[0m""download " ftp://ftp.freedesktop.org/pub/mesa/older-versions/7.x/7.8.1/MesaLib-7.8.1.t…); \ (test -f $name || wget --quiet ftp://ftp.freedesktop.org/pub/mesa/older-versions/7.x/7.8.1/MesaLib-7.8.1.t… -O $name); \ (echo -e "74e72b56c7ae779649c18867fe9e0865f3bfc057 MesaLib-7.8.1.tar.gz" |\ sha1sum -c > /dev/null 2> /dev/null) || \ (echo -e Error: Hash sum check for mesa failed; false) Error: Hash sum check for mesa failed make[2]: *** [mesa.file] Error 1 and also, I'm not using base-pistachio so I'm not sure if the following error is on my linux mint box or not: -------------------------- Cloning into 'src/kernel/pistachio'... pistachio update src/kernel/pistachio sed -i "/LD=/s/^.*$/LD=\$(CC)/" src/kernel/pistachio/user/config.mk.in sed -i "s/-melf_/-Wl,-melf_/" `grep -rl melf_ src/kernel/pistachio/user` for i in cmlcompile.py cmlconfigure.py configtrans.py; do \ sed -i "s/env python/env python2.7/" src/kernel/pistachio/contrib/cml2/$i; done cd src/kernel/pistachio/user; autoheader; autoconf; autoconf: Undefined macros: configure.in:117:AC_CONFIG_HEADERS([config.h]) configure.in:129: [AC_HELP_STRING([--with-comport=PORT], configure.in:138: [AC_HELP_STRING([--with-comspeed=SPEED], configure.in:147: [AC_HELP_STRING([--with-kickstart-linkbase=BASE], configure.in:152: [AC_HELP_STRING([--with-s0-linkbase=BASE], configure.in:157: [AC_HELP_STRING([--with-roottask-linkbase=BASE], configure.in:162: [AC_HELP_STRING([--with-kerneldir=DIR], configure.in:341:AC_CONFIG_FILES([ configure.in:36:AC_CONFIG_SRCDIR([serv/sigma0/sigma0.cc]) make[2]: *** [additional_steps] Error 1 Regards, dex

3 6

Planning for Genode on Risc-V ?
by Peter Lindener 03 Sep '14

03 Sep '14

Dear Norman and fellow Genodians.. Taking note of Johanne's efforts to bring up the Genode OS to run on the LEON_3 CPU <http://www.gaisler.com/index.php/products/processors/leon3>... prompted me to do a little catching up. Risc-V <http://riscv.org/> the current very promising state of Open source CPU core design.... here is the current state of Risc_V's software tool chain <http://riscv.org/download.html#tab_tools>... ..it seems we might want to think about how Genode's tool chain support could evolve to handle this fairly promising open Risc platform.... such that as lowRISC <http://www.lowrisc.org/> come's into it's existence, running Genode on it might be just the ticket. all the best -Peter

2 2

Trouble booting Genode examples on RaspberryPI
by Reinier Millo Sánchez 02 Sep '14

02 Sep '14

Hi I'm tried run Genode Demo for RaspberryPI on real hardware. I have compiled the example demo and the printf demo. For each test case i have copied the image.elf to the PI, and create the config.txt file with the line kernel=image.elf. When the RPI boot only show the colored screen, and anything more. I have missed any steps to boot Genode on RPI? Best regards -- Lic. Reinier Millo SÃ¡nchez Centro de Estudios de InformÃ¡tica Universidad Central "Marta Abreu" de Las Villas

2 1

Re: Re: Re: Some questions about performance optimization related to GUI framework on Genode
by 王硕 02 Sep '14

02 Sep '14

Hello Norman, The Git branch of our genode is listed below: https://github.com/kloisiie/vsos Sorry for my disturbance, and the answer of questions which you asked me before are listed below: * Which version of Genode are you using? 13.02. Now I'm trying to transplant apps on genode 14.05 and base-foc. * Are you using Qt4 or Qt5? (If you are still using Qt4, I would recommend you to switch to Qt5) Qt4. * Which Genode base platform are you using? Fiasco.OC. (base-foc) * Have you tried to run your GUI application on base-linux? If yes, have you compared its performance to the same application compiled for native Linux w/o Genode? Our apps is Fiasco.OC-specific, so I don't know how to run these apps on base-linux. * On base-linux, you could use normal Linux profiling tools such as oprofile to find out where the CPU time goes. Please recommend some similar tools on base-foc. * Can you make a Git branch with your application publicly available‍ https://github.com/kloisiie/vsos‍ To run the vsos, use $ ./create_builddir fox_x86_32 build_dir=~/<build-directory> to create a build directory, and then execute $ make run/verify in build directory. Thank you for all your assistance.‍ Shuo Wang, University of Chinese Academy of Sciences. Re: Some questions about performance optimization related to GUI framework on Genode From: Norman Feske <norman.feske@...265...> - 2014-03-27 13:45:31 Hello Shuo Wang, thank you for your interest in Genode! Please excuse the delayed response. I was offline for a few days. > The most serious problem I meet now is that system is very slow when > running applications we made before, so I doubt whether this is related > to GUI framework. I plan to transplant DoPE to Genode, in order to make > a comparation between DoPE and Qt. But I am worried about reasonability > about my design of experiments, so I need help from the developers. DOpE is definitely faster than Qt as it is even usable on low-performance devices such as FPGA softcores, e.g., the Milkymist SoC [1]. So for those kind of special-purpose appliances, DOpE still seems to be attractive. However, in the context of the Genode OS framework, I would advise against using DOpE. I would rather spend the energy on investigating the performance problems you observe with Qt. [1] http://m-labs.hk/m1.html The reason for my stance is that DOpE lacks a lot of features that are universally expected from modern GUI toolkits (e.g., support for theming, international characters, common widget types like menus). Furthermore, it has been practically unmaintained for several years now. If you still like to go forward with experimenting with DOpE on Genode, I can possibly assist you. I already ported DOpE to an early version of Genode in 2008 and could possibly revive the port. However, I am not committed to actively maintain or even improve it. As I said above, I would rather try to find out why Qt performs so badly for you. This raises the following questions: * Which version of Genode are you using? * Are you using Qt4 or Qt5? (If you are still using Qt4, I would recommend you to switch to Qt5) * Which Genode base platform are you using? * Have you tried to run your GUI application on base-linux? If yes, have you compared its performance to the same application compiled for native Linux w/o Genode? * On base-linux, you could use normal Linux profiling tools such as oprofile to find out where the CPU time goes. * Can you make a Git branch with your application publicly available (e.g., on Github) so that I could give it a try? By being able to reproduce the problem, I could help you much better with investigating the issue. Best regards 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

2 4

Native keyboard driver on Genode for imx6
by Swaminathan Ramesh 01 Sep '14

01 Sep '14

Hello Norman, We are the team at IIT-Madras trying to port Genode on imx6. We are currently trying to create a shell for Genode natively. Towards this end, we would like to create a native keyboard driver on Genode. It would be great if you could give us a few tips to getting started on it. Thanks, -- Best regards, Swaminathan Ramesh

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users September 2014