users April 2014

users@lists.genode.org

23 participants
24 discussions

netperf
by Анна Будкина 07 Jun '16

07 Jun '16

Hello! I'm running netperf TCP_STREAM and TCP_MAERTS tests for lxip stack and i obtained extremely low result - 5x10^6 bits/s while the maximum throughput is 1000 mbit/s . I wonder what could be the reason for that. Anna

6 16

Re: Genode Hack'n Hike 2013
by Norman Feske 23 Mar '15

23 Mar '15

Hello everyone, the date for this year's Genode Hack'n Hike held during 11-16 of September is approaching. Genode's developers will spend those days in the beautiful scenery of the Bohemian Switzerland, relaxing, hiking, and hacking on fun side projects. The Hack'n Hike will be the perfect setting for getting involved with the community, catching up, or just hanging out with the Genode crowd. There is still room for more participants. Genode Labs sponsors the event. So your participation/accommodation is free. If you like to join in, please get in touch by writing to hacknhike@...1... or commenting on https://github.com/genodelabs/genode/issues/793. Cheers Norman On 07/25/2013 02:38 PM, Norman Feske wrote: > Hello, > > let me get back to this year's Genode Hack'n Hike planned for the 11th > to 16th of September. Since I posted the initial announcement (below), > we settled for a beautiful location in the Bohemian Switzerland in Czech > Republic. Check out the following links for wetting your appetite: > > http://goo.gl/maps/TAZc1 > http://www.kristinhradek.cz/en > > The location lends itself to a multitude of leisure activities. For > planning those activities and to discuss topics around the Hack'n Hike > event, there is a dedicated issue in the Genode issue tracker: > > https://github.com/genodelabs/genode/issues/793 > > Please feel welcome to join in, whether to stay the whole time or just > for a short visit. Genode Labs will sponsor the accommodation, but the > available space is limited. If you consider to join this year's Hack'n > Hike, please send a short notice to the following email address to > register your participation: > > hacknhike@...1... > > Cheers > Norman > > On 06/05/2013 12:42 PM, Norman Feske wrote: >> Hello, >> >> I'd like to share the following excerpt of the latest Genode-Labs >> newsletter with you: >> >> >> Join us at Genode's Hack'n Hike event >> ------------------------------------- >> >> In spring of 2012, we held the first instance of the Genode Hack'n >> Hike, which were wonderful days full of hacking, relaxing, brain- >> storming, and enjoying the magnificent nature of the Saxon Switzerland >> together. From the feedback we got from the attendees, it goes >> without saying that this should not stay a singular event, but >> rather be the prelude of a tradition. Hence, we have fixed the date >> for this year's Hack'n Hike: >> >> Begin: Wednesday, September 11 >> End: Monday, September 16 >> >> We extended the duration of the event over that of last year's. >> Whether you'd like to drop by for just a few hours, or you'd like to >> stay for the whole time, you are welcome to join in. Genode Labs >> will sponsor the accommodation. So don't worry too much about the >> costs. >> >> As of now, we haven't finalized the decision about the venue, but >> you can be sure that it will be a beautiful and romantic place, >> presumably in Saxony/Germany or Bohemian Switzerland in Czech >> Republic. If you have particular preferences regarding the >> accommodation or leisure-time activities, then the best time to get >> in touch with us is now. Also, if you plan attending, we'd greatly >> appreciate a short notice, which will help us with planning ahead. >> Please write to: >> >> hacknhike@...1... >> >> We at Genode Labs are looking forward to the gathering of the Genode >> community in autumn and would love to welcome you! >> >> ------ >> >> For the full newsletter, please refer to >> >> http://genode-labs.com/news/newsletter/newsletter-2013-05 >> >> 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 ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Genode-announce mailing list Genode-announce(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-announce

2 1

AW: Block Cache
by Wolfgang Schmidt 15 Jun '14

15 Jun '14

Hi Stefan, Can You give a gibt for compatible x86 hw? I tried The democd on an FSC Athlon64 which did mit start at all. Does for example a comp list for nova exist? What so You mean with: it serves only one client- one client application? Best regards Wolfgang ----- Ursprüngliche Nachricht ----- Von: "Stefan Kalkowski" <stefan.kalkowski@...1...> Gesendet: ‎28.‎04.‎2014 21:13 An: "genode-main(a)lists.sourceforge.net" <genode-main(a)lists.sourceforge.net> Betreff: Re: Block Cache Hi Wolfgang, On 04/28/2014 08:27 PM, w_schmidt@...181... wrote: > Hello, > > I have a few question regarding genodes block cache in 14.02. > > If understand it correctly on x86-based computers genode starts on top of > linux. well, that's not true. Yes, Genode is able to run on top of Linux, mostly for development purposes. But Genode runs also directly on x86 hardware using the NOVA kernel, or Fiasco.OC kernel, or the OKL4 kernel, or Pistachio kernel. > Therefore multiple caches will be used before something goes to genode > a) the cache on a hdd > b) cache on a drive controller > c) the linux block cache If running on Linux yes, but normally it wouldn't make much sense to use an additional block cache here. > d) qemu As already said: you don't need to use Qemu. Most run scripts are starting Qemu by default, for convenience reasons only. > > The first one is about the scenario in which the block cache is used. > Is the block cache only thought for embedded devices where genode runs > nativly? Are all embeded devices usable with the cache? The block cache uses the block session of Genode. It uses exactly one block device, and serves exectly one client. As all block device drivers of Genode are implementing the block session interface, the block cache can be used on top of all block drivers, whether its a x86 AHCI driver, or MMC card driver of an ARM SoC, or whatever. > > Is there a way to mount a partition in genode with qemu without using caches > from c) and d) ? > Or is there a x86 hardware where genode can directly operate on? Qemu allows to define the caching policy of a hard drive (cache=none). I don't know whether it's possible to circumvent Linux block cache. I assume that's hard. But as mentioned above, you can use conventional x86 PC hardware. Regards Stefan > > As far as I have seen so far the disc cache of Linux does not seem to be > disablable. I have only foudn ways to flush linux cache (like sync && echo 3 > > /proc/sys/vm/drop_caches). > > Best regards, > Wolfgang > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Genode-main mailing list > Genode-main(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Genode-main mailing list Genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

4 6

PingPong Example for the LWIP
by Mhamad Hmad 03 Jun '14

03 Jun '14

Hello, i am still new to the Genode so maybe you will find that my question is silly but i tried to run the PingPong example but i failed i build the Genode for base_linux i enabled the libport repository fron the build.conf then i prepare for the PKG=Lwip from the build directory i tried to run the server as next make run/test-ping_server and it is run successfully. when i try to do that for the client i could not success i hope some one can help .. i am sure i need to change in some values but actually i couldn't know where . -- *Mohammad*

4 4

Docker app containers for Genode?
by Peter Lindener 13 May '14

13 May '14

RedHat<http://www.redhat.com/about/news/press-archive/2014/4/red-hat-docker-expand…>, and Ubuntu<http://www.infoworld.com/t/linux/ubuntu-chases-after-red-hat-openstack-and-…>bot seem to be incorporating Docker <https://www.docker.io/>'s application packaging into there plans...any thoughts on how Docker might come to influence Genode's longer term road-map? -Peter

4 7

genome and i.mx53 quick start board
by Sileshi Demesie 30 Apr '14

30 Apr '14

Dear Sir/Madam, I am working on i.mx53 quick start board to manage the trust zone technology. I want to install genode on top of ubuntu or android so that I can run genode in the secure world and ubuntu/Android in the normal world. If can these two worlds , then I can to run trusted applications in the secure world(genode). Could you please give me brief explanation on how I can manage those things? thank you in advance. regards, Sileshi

2 1

AW: AW: Block Cache
by Wolfgang Schmidt 30 Apr '14

30 Apr '14

Hi, The last time the build Problem was mit on Hardware, but on building it with the run/Demo for qemu. This now works after the comments. What haven't worked right now is using the live cd on real hardware. ( neither older L4 mir newer Linux live Demo) So I asked to know wether a specific Plattform is known to work as I habe no Nova knowledge so far ( to reduce the risk of asking to many stupid questions). Of I understand You correctly the was of using a filesystem with cache wozld be ahci as driver -> blockcache as server -> rump_fs as single client of the blockcache and as server for -> multiple programs accessing files. Is this correct? Best regards Wolfgang ----- Ursprüngliche Nachricht ----- Von: "Stefan Kalkowski" <stefan.kalkowski@...1...> Gesendet: ‎29.‎04.‎2014 09:37 An: "genode-main(a)lists.sourceforge.net" <genode-main(a)lists.sourceforge.net> Betreff: Re: AW: Block Cache Hi Wolfgang On 04/28/2014 10:25 PM, Wolfgang Schmidt wrote: > Hi Stefan, > Can You give a gibt for compatible x86 hw? I tried The democd on an FSC > Athlon64 which did mit start at all. Does for example a comp list for > nova exist? No, I've no compatibility list available. I know of quite different Intel PCs people are using doing experiments with Genode/NOVA. What do you mean with it didn't start at all on your specific hardware? The last time I've read an email from you regarding problems with NOVA on real hardware, it failed to compile the framebuffer driver, because your third-party-code "libports" repository probably wasn't prepare accordingly. Maybe it's better to smooth build problems out, instead of searching for new hardware? > > What so You mean with: it serves only one client- one client application? I meant, the block cache acts like a block driver. In general a block driver in Genode serves only one client, e.g.: a filesystem server. If you want to share the same device with multiple clients, you might use the "part_blk" server, which provides different partitions, found on the device, as separate block sessions to different clients. Does that clarifies your question? Regards Stefan > > Best regards > Wolfgang > ------------------------------------------------------------------------ > Von: Stefan Kalkowski <mailto:stefan.kalkowski@...1...> > Gesendet: ‎28.‎04.‎2014 21:13 > An: genode-main(a)lists.sourceforge.net > <mailto:genode-main@lists.sourceforge.net> > Betreff: Re: Block Cache > > Hi Wolfgang, > > On 04/28/2014 08:27 PM, w_schmidt@...181... wrote: >> Hello,, >> >> I have a few question regarding genodes block cache in 14.02. >> >> If understand it correctly on x86-based computers genode starts on top of >> linux. > > well, that's not true. Yes, Genode is able to run on top of Linux, > mostly for development purposes. But Genode runs also directly on x86 > hardware using the NOVA kernel, or Fiasco.OC kernel, or the OKL4 kernel, > or Pistachio kernel. > >> Therefore multiple caches will be used before something goes to genode >> a) the cache on a hdd >> b) cache on a drive controller >> c) the linux block cache > > If running on Linux yes, but normally it wouldn't make much sense to use > an additional block cache here. > >> d) qemu > > As already said: you don't need to use Qemu. Most run scripts are > starting Qemu by default, for convenience reasons only. > >> >> The first one is about the scenario in which the block cache is used. >> Is the block cache only thought for embedded devices where genode runs >> nativly? Are all embeded devices usable with the cache? > > The block cache uses the block session of Genode. It uses exactly one > block device, and serves exectly one client. As all block device drivers > of Genode are implementing the block session interface, the block cache > can be used on top of all block drivers, whether its a x86 AHCI driver, > or MMC card driver of an ARM SoC, or whatever. > >> >> Is there a way to mount a partition in genode with qemu without using > caches >> from c) and d) ? >> Or is there a x86 hardware where genode can directly operate on? > > Qemu allows to define the caching policy of a hard drive (cache=none). I > don't know whether it's possible to circumvent Linux block cache. I > assume that's hard. > But as mentioned above, you can use conventional x86 PC hardware. > > Regards > Stefan > >> >> As far as I have seen so far the disc cache of Linux does not seem to be >> disablable. I have only foudn ways to flush linux cache (like sync && > echo 3 >> > /proc/sys/vm/drop_caches). >> >> Best regards, >> Wolfgang >> >> >> > ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform > available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Genode-main mailing list >> Genode-main(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/genode-main >> > > -- > Stefan Kalkowski > Genode Labs > > http://www.genode-labs.com/ · http://genode.org/ > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Genode-main mailing list > Genode-main(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > > > > _______________________________________________ > Genode-main mailing list > Genode-main(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Genode-main mailing list Genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

2 1

manually constructing the type list of RPC functions
by Mhamad Hmad 28 Apr '14

28 Apr '14

hi , the RPC function number in each interface is limited by 9 , I have more than 9 functions . Genode have away to do that by manually constructing the type list of RPC functions instead of using the convenience macro typedef Meta::Type_tuple<Rpc_myfunc1, Meta::Type_tuple<Rpc_myfunc2, Meta::Empty> > Rpc_functions; I add that to my intrface session but i get the next error *error: ‘Meta’ does not name a type* and another error * no type named ‘Rpc_functions’ in ‘struct myrpcsession::Session’* I looked to the "cpu_session.h" and tried to do same but i think i miss some thing . any clue? best , mohammad

2 4

make run/demo stop unexpectedly
by Sun Keqin 28 Apr '14

28 Apr '14

Hi, My colleague met a very strange problem today, so I ask for help. There is an error when he run "make run/demo” in build directory, however, when he run "qemu-system-i386 -no-kvm -m 256 -serial mon:stdio -cdrom var/run/demo.iso" directly, it works successfully. Do you know why it happened? What should I do to fix that? Here is the details. genode build completed using fiasco kernel /home/jimmy/work/os/genode/build/kernel/fiasco.oc/fiasco using sigma0/bootstrap at /home/jimmy/work/os/genode/build/l4 creating ISO image... spawn qemu-system-i386 -no-kvm -m 256 -serial mon:stdio -cdrom var/run/demo.iso L4 Bootstrapper Build: #1 2014: spawn id exp6 not open while executing "expect { -i $running_spawn_id -re $wait_for_re { } eof { puts stderr "Error: Spawned process died unexpectedly"; exit -3 } timeout { puts ..." (procedure "wait_for_output" line 11) invoked from within "wait_for_output $wait_for_re $timeout_value $qemu_spawn_id" (procedure "spawn_qemu" line 51) invoked from within "spawn_qemu $wait_for_re $timeout_value" (procedure "run_genode_until" line 18) invoked from within "run_genode_until forever" (file "/home/jimmy/work/os/genode/genode-13.05/os/run/demo.run" line 139) invoked from within "source $include_name" ("foreach" body line 3) invoked from within "foreach include_name [get_cmd_arg --include ""] { puts "using run script $include_name" source $include_name }" (file "/home/jimmy/work/os/genode/genode-13.05/tool/run" line 730) Cheers, keqin

4 4

Major revision of the C runtime (VFS)
by Norman Feske 28 Apr '14

28 Apr '14

Hello, I have just merged a significant change of the C runtime into our staging branch. Because this change will likely affect users of the framework (hopefully for the better ;-), I'd like to bring up this topic here. Since many years, our C runtime served us quite well, thanks to the plugin architecture that allows us to combine different backends such the lwIP socket API using libc_lwip_nic_dhcp, using LOG as stdout via libc_log, or using a ROM dataspace as a file via libc_rom. However, the original design of the plugin architecture is starting to show its limitations. Examples of the current limitations: * There is a libc_fs plugin that allows a program to access files from a file-system server. But there is no way to allow one program to access two different file-system servers. * There is a libc_block plugin that hands out a block session as a pseudo block device named '/dev/blkdev'. However, when combined with libc_fs, it is not defined which of both plugins will handle the file with this name. As a quick and dirty work-around, the libc_fs plugin explicitly black-lists '/dev/blkdev'. * In general, if multiple plugins are combined, there is no consistent virtual file system structure exposed via getdirentries. * There is no flexible concept for handling stdio. Most programs use libc_log to direct stdout to the LOG service. But what if we want to direct the output of such a program to a terminal? Granted, there exists the 'terminal_log' server to translate a LOG session to a terminal session but it would be much nicer to have this flexibility at the C runtime level. * Many libc plugins look similar. There are quite a few dusty corners where duplicated code has been accumulated over the years. That said, the semantic details (e.g., the quality of error handling) differ from plugin to plugin. Seeing the number of file systems (and thereby the number of added libc plugins) growing, it became apparent that our original design would not scale too well. On the other hand, we have gathered very positive experiences with the virtual file system implementation of Noux. It allows to us have a coherent VFS with support for stacked file systems (similar to union mounts) of various types. The VFS of Noux is stable and complete enough to accommodate our tool chain. Wouldn't it be a good idea to reuse the Noux VFS for the normal libc? This line of thoughts led to the following issue: https://github.com/genodelabs/genode/issues/999 The result of this line of work has been merged into the staging branch now. I adapted most of the run scripts and targets to the changed libc but certainly missed a few bits. I.e., the following run scripts remain untested and are expected to fail in one way of another: * http_srv_tracing_nonblocking_panda * qt_avplay (the qt4 version) * netperf * l4linux_dynamic * noux_gdb_dynamic * debug_nitpicker * noux_gdb * virtualbox * virtualbox_auto I would appreciate your help to rectify them, so that we can merge the staging branch to the master branch soon. How has the libc changed? Each libc-using program can be configured with a program-local virtual file system as illustrated by the following example: <config> ... <libc stdin="/dev/null" stdout="/dev/log" stderr="/dev/log"> <vfs> <dir name="dev"> <log/> <null/> </dir> <dir name="etc"> <dir name="lighttpd"> <inline name="lighttpd.conf"> ... </inline> </dir> </dir> <dir name="website"> <tar name="website.tar"/> </dir> </vfs> </libc> </config> Here you see a lighttpd server that serves a website coming from a TAR archive (which is obtained from a ROM module named "website.tar"). There are two pseudo devices "/dev/log" and "/dev/null", to which the "stdin", "stdout", and "stderr" attributes refer. The "log" file system consists of a single node that represents a LOG session. The web server configuration is supplied inline as part of the config. (Btw, you can try out a very similar scenario using the 'ports/genode_org.run' script) The VFS implementation resides at 'os/include/vfs/'. This is where you can see the file system types that are available (look for '*_file_system.h' files). Because the same code is used by Noux, we have one unified and coherent VFS implementation throughout the framework now. There are two things needed to adapt your work to the change. * Remove the use of the libc_{rom, block, log, fs} plugins from your target description files. Those plugins are no more. As of now, the VFS is still internally a plugin, but it is always included with the libc. * Configure the VFS of your libc-using program in your run script. For most former users of the sole libc_log plugin, this configuration looks like this: <config> <libc stdout="/dev/log" stderr="/dev/log"> <vfs> <dir name="dev"> <log/> </dir> </vfs> </libc> </config> For former users of the other plugins, there are the 'block', 'rom', and 'fs' file-system types available. I hope that you will like the new VFS infrastructure. If you have any questions, bug reports, or critique, feedback is always welcome. 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

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users April 2014