users

users@lists.genode.org

7 participants
2306 discussions

compiling genode with Virtual box tiny core Linux
by Janardhan 27 Apr '17

27 Apr '17

Hi, I am trying to compile genode with the support of virtual box and tiny core Linux .While compiling i am getting below error library dependencies... Library cxx Library alarm Library timed_semaphore Library config Library startup-nova Library base-nova-common Library base-nova Library ldso-startup Library ld-nova Program lib/ld/nova/ld-nova Program kernel/nova/hypervisor make[1]: Leaving directory `/home/janardhan/genode/build/nova_x86_64' genode build completed using 'ld-nova.lib.so' as 'ld.lib.so' using 'nova_timer_drv' as 'timer' cp: cannot stat ‘bin/virtualbox-nova’: No such file or directory while executing "exec cp bin/[kernel_specific_binary $binary] [run_dir]/genode/$binary" (procedure "copy_and_strip_genode_binaries_to_run_dir" line 4) invoked from within "copy_and_strip_genode_binaries_to_run_dir $modules" (procedure "build_core_image" line 8) invoked from within "build_core_image $binaries" (procedure "run_boot_dir" line 12) invoked from within "run_boot_dir $binaries" (procedure "build_boot_image" line 2) invoked from within "build_boot_image $boot_modules" (file "/home/janardhan/genode/repos/ports/run/virtualbox.run" line 181) invoked from within "source $include_name" ("foreach" body line 6) invoked from within "foreach include_name [get_cmd_arg --include ""] { # first check if the include name is absolute if {[string first "/" $include_name] == 0} { puts ..." (file "/home/janardhan/genode/tool/run/run" line 809) make: *** [run/virtualbox] Error 1 Can any one help?

6 19

base-hw Bootstrap implementation: 16.05 version vs. 17.02 version
by Vasan VS 22 Apr '17

22 Apr '17

Hi all, We are trying to build and run Genode on a custom board with iMX6 processor. As part of this process, we are trying to understand the implementation of base-hw in the 17.02 version release. In trying to understand the implementation of base-hw in the 16.05 implementation and in the current 17.02 version, we find that the bootstrap portion of the implementation is present in 17.02 source base @ base-hw/src/bootstrap which is NOT present in 16.05 code base. We had a look at the detailed release notes of all the intermediate releases between these two versions (16.05->16.08, 16.08->16.11, 16.11->17.02) but we could not find any documentation of the changes that has been done on this particular portion of base-hw between these two releases. If we use the 16.05 version on our board, we get the "Kernel initialized" message after init is started but on the 17.02 version, the board is hanging and refusing to boot up after "Starting kernel" message(from uboot). Can someone help us with the following: a) Provide the details of the changes that has been done between the two versions in the bootstrap portion b) Point us to any clues on why we are facing this hang problem after the log service is initialized and while enabling the MMU and caches. Thanks in advance, Vasan

2 2

Re: Ideas about interactive GUI
by Boris Mulder 21 Apr '17

21 Apr '17

Hi, Good to hear that you are also going to do this! For us, there is a clear need for a GUI system that is both dynamic and simple in use. > This is actually very similar to what the existing menu_view already > gives you. This configurablility would indeed be similar to menu_view. Another main difference is that it does not aim to replace menu_view, but is an overlapping component that could also handle input, and take actions, such as collapsing and expanding submenus. It could still use menu_view, fading_dialog and such parts. So instead it aims to replace the menu part of launcher, except that it is dynamic and generic. What we would like is such a menu component that could be used at many places; not only for a desktop environment, but also inside any application, or settings menu, or subsystem. It would be complete with elements such as buttons, submenus and dialogs, and the notion of clicking on these elements. These events could somehow be communicated to other elements such that the corresponding actions are taken. > I'd advise not to use the report/ROM interface to propagate events, but > only state. Even though one (myself included) is sometimes intuitively > tempted to mix up events and states, it calls for trouble. > [...] Makes sense, you are right. However, for clicking buttons in this context, it makes sense to communicate events instead of states. Perhaps using another way than reports could be useful here, such as some list of events like in Input, or a packet-stream like functionality. > This raises the question of where does the responsibility of the menu > end, and where do the responsibilities of the subsystem manager start? > If we need a subsystem manager anyway, couldn't it use the menu_view(s) > directly to implement menus? We would like to separate the menu with all its buttons from the subsystem state logic. Whenever we want an application that uses the GUI that does different things, we would have to import the menu management code into these applications. This could be done as a library with functions for creating buttons and menus, or as a separate component that can be configured and uses some IPC mechanism. In the latter case, more than one component can talk with the same menu, depending on the application programmer's needs. This can be made as complex or simple as is desirable. However now it is already quite complicated to create only a basic menu as all the features are very intertwined, which makes the code a bit hard to read and modify. > The answer may depend on the complexity of the subsystem manager, which > is obviously critical. Does the separation of the menu from the > subsystem manager contribute to significantly lower the TCB of the > subsystem manager? It does not necessarily change the TCB, but it is done for the sake of reusability and code readability/ease of programming. From that perspective we think it would be nice if these things were separated, and for instance the menu part could be used in another application as well. > This leaves the question about the input focus. When using the wm, the > focus is already defined by the window layouter via the 'focus' ROM. The > window layouter, in turn, already consumes a 'focus_request' ROM to > respond to externally triggered focus changes. This would be the right > hook for the menu / subsystem manager. I've been looking into this mechanism, but so far it's not entirely clear to me. Do you mean that the subsystem manager could write to this focus_request report and the layouter would for example show/hide the appropriate windows automatically? If so, what about the focus_requests that come from the window manager? In short: how would that work? > The state report generated by init already contains a 'state' attribute > for each child. Right now, the attribute is present only if the child is > "incomplete". We could add a value "exited" that would be presented as > soon as the child issued a 'Parent::exit' call. Also the exit code could > be added to the report, if needed. The subsystem manager could then > inspect the state reports for children with this attribute value and > remove them from the init config. This is exactly what I'm looking for in that case. Thanks, -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)

3 3

Genode compilation with virtual box and tiny core Linux
by janardhan 20 Apr '17

20 Apr '17

Hi, I am compiling Genode with Virtual box and tiny core Linux.Linux .While compiling i am getting below error's make[1]: Leaving directory `/home/janardhan/genode/build/nova_x86_64' genode build completed using 'ld-nova.lib.so' as 'ld.lib.so' using 'nova_timer_drv' as 'timer' cp: cannot stat ‘bin/virtualbox-nova’: No such file or directory while executing "exec cp bin/[kernel_specific_binary $binary] [run_dir]/genode/$binary" (procedure "copy_and_strip_genode_binaries_to_run_dir" line 4) invoked from within "copy_and_strip_genode_binaries_to_run_dir $modules" (procedure "build_core_image" line 8) invoked from within "build_core_image $binaries" (procedure "run_boot_dir" line 12) invoked from within "run_boot_dir $binaries" (procedure "build_boot_image" line 2) invoked from within "build_boot_image $boot_modules" (file "/home/janardhan/genode/repos/ports/run/virtualbox.run" line 181) invoked from within "source $include_name" ("foreach" body line 6) invoked from within "foreach include_name [get_cmd_arg --include ""] { # first check if the include name is absolute if {[string first "/" $include_name] == 0} { puts ..." (file "/home/janardhan/genode/tool/run/run" line 809) make: *** [run/virtualbox] Error 1 Can any one help?

1 0

Now: Nova not maintained [Earlier]: Understanding Muen [Earlier] Re: Problem with make run/demo ....
by Shahbaz khan 19 Apr '17

19 Apr '17

Hi Nobody, Please don't mind my changing the subject title. On Tue, Apr 18, 2017 at 11:44 PM, Nobody III <hungryninja101@...9...> wrote: > By the way, NOVA doesn't seem to be maintained anymore, except a bit by > Genode developers. Is this observation correct? > My observation is that most of the innovations were achieved by 2012 in microkernel research so stable work is what we see in Fiasco.oc and Nova. The only problem was that these OSes could not be formally verified. Muen answers the problem by hardcore simplicity, while I believe SEL4 has practicality issues. Formal verification is not interesting for developers so somehow funds went somewhere else. Just a thought. Rest is driver development which is not a research and showcase problem and handed by industry rather than universities, TUD Genode people are the pioneers and can answer better. Regards, Shahbaz

2 2

Re: Now: Understanding Muen and base_hw kernel from docs, [Earlier] Re: Problem with make run/demo ....
by Shahbaz khan 19 Apr '17

19 Apr '17

Dear Norman, On 17.04.2017 19:53, Shahbaz khan wrote: > > VirtualBox closely interacts with the virtualization hardware. On > Muen, > > this interaction naturally has to go through the Muen SK. By using > > Genode as runtime for VirtualBox, Muen is able to leverage Genode's > > existing solution of the interaction of VirtualBox with a > > microkernel-based virtualization mechanism. > > > > > > Similar to karma-vmm, fiasco.oc and l4linux. > > I don't see the connection. My email was not related to Fiasco.OC, > Karma, or L4Linux. > I think I got the problem. Muen subject is not a subject like that of an OS. > > > Conceptually, a Muen partition is a hardware platform, similar to a > > board. Like on any board, you can run software directly (in > supervisor > > mode). But for running a complex software stack, or more than one > > application, one has to use an operating system (OS). Genode/base-hw > > plays this role. > > > > > > Simply put a build time think. Base-hw kernel means muen sk for genode > > runtime. > > Muen can be used without base-hw. > Base-hw can be used without Muen. > Second problem in my mind would be imagining the spartan environment provided by Muen to be fulfilled with Genode runtime minus microkernel. This would be as follows. Base-HW is a microkernel as you mentioned earlier. Like a layman I ask the name of this microkernel. Is it Nova? Again to my preliminary question ... we run a micro-kernel on microkernel to run virtualbox rather than virtualbox on Muen SK. > > But when combined, Genode's version of VirtualBox can run on top of Muen. > Muen is a micro-hypervisor. What is the nature of inter-subject communication? Considering we don't like pure hypervisor approach. I liked Nova's architecture much more and I would opt for Nova if formal verification could be as simple for it as in Muen. And the luxury of C++ too. Regards, Shahbaz

3 2

Genode, seL4 and VirtualBox
by Chris Rothrock 18 Apr '17

18 Apr '17

I'm working with the team at Critical Technologies and I am trying to get this combination to work - Genode with seL4 microkernel and the VirtualBox module (using TinyCore Linux). Let me first start off with saying that Genode, Nova and VirtualBox works flawlessly - I can boot (an Intel-based machine) and go into either a command line or GUI environment. The problem is when I try using seL4. I can compile this without any errors. The ISO image is made perfectly, it boots to this image on the same hardware - but that's where it stops. One time only I was able to see the loading screen of TinyCore Linux within VirtualBox but the boot time for this took about 45 minutes and I was unable to reproduce this boot. I guess my first question is this - does seL4 have the necessary virtualization support for this module? If so, how can I make this work reliably? -- Thank You, Chris Rothrock Senior System Administrator (315) 308-1637

3 3

Now: Suitable ARM alt. to Fiasco.OC [Earlier]: Understand Muen scenario, [Earlier] Re: Problem with make run/demo ....
by Shahbaz khan 18 Apr '17

18 Apr '17

> > Base-HW is unrelated to NOVA or any of the other kernels. It is a > > microkernel specifically developed for and tightly integrated with > > Genode. Think of it as an optional back end of Genode to run > > Genode-based systems directly on hardware (or virtual hardware like a > > Muen partition) without a third-party kernel. > > > > > > By the way it seems fiasco.oc is not being maintained. Is something > > better available, which supports both micrkernel based runtime and > > virtualization..? > > At Genode Labs, we primarily focus on NOVA, base-hw, and seL4. All these > kernels are third-generation modern microkernels [1]. For using Genode > on x86 PC hardware, NOVA is the best way to go right now. > > Genode is also able to run on Fiasco.OC but we don't actively facilitate > it. E.g., we dropped the support for L4Linux (Fiasco.OC-specific > paravirtualized Linux) earlier this year [2]. > What is the ARM alternative to Fiasco.OC? That is supporting micro-kernel subjects as well as virtual machines. Will it make sense if we (my team) supports Fiasco.OC if suitable microkernel is not available for ARM? In case of X86 Muen seems to be the best as I am interested in formal verification like everyone else. Fiasco.OC is troublesome when it comes to formal verification. Regards, Shahbaz Khan

1 0

Now: Understanding Muen and base_hw kernel from docs, [Earlier] Re: Problem with make run/demo ....
by Shahbaz khan 18 Apr '17

18 Apr '17

On Fri, Apr 14, 2017 at 10:28 AM, Nobody III <hungryninja101@...9...> wrote: > I've been wondering, is there any reason not to use base-hw_x86_64_muen on > regular hardware? It seems to work fine in Qemu, and > Release notes mention Thinkpad X201.Muen website makes me cautious but if Qemu works then we are good for a start. Have your tried virtualbox? So bochs is not mandatory. > almost all Genode drivers are in userspace. Is there some limitation that > I'm not aware of? > > Well anything is easily possible with micro-kernel architecture in concept but I was curious whether we run base_hw kernel that is muen according to mainline repo's files. The diagram from release notes depict base_hw kernel on Muen SK. It still does not make sense to me. I will have to look later as I am working on some basic presentation on Muen and genode for some prospects. > > On Thu, Apr 13, 2017 at 1:38 PM, Shahbaz khan <shazalive@...9...> wrote: > >> >> >> On Wed, Apr 5, 2017 at 2:36 PM, Christian Helmuth < >> christian.helmuth@...1...> wrote: >> >>> On Wed, Apr 05, 2017 at 11:54:47AM +0500, Shahbaz khan wrote: >>> > I have started working with Genode, while I am interested in foc based >>> > development and it seems the Genode efforts also prefer foc as I have >>> been >>> > trying run/demo for builds. >>> >>> I would not go along with telling that we "prefer" base-foc as most of >>> our scenarios run on all supported kernels. Prominent exceptions are >>> support for hardware virtualization (only on NOVA and hw/Muen) and >>> TrustZone (hw only). If you address ARM and x86 alike I'd suggest you >>> try out base-hw. >>> >> >> I got a bit acquainted with the release notes but I still find it >> difficult to comprehend what really base-hw means when we say "Genode base >> -hw" on Muen SK. >> >> I am having some build issues (I do get an image.elf but build does not >> complete) and have yet not looked into earlier commits and branches so I >> would appreciate if you can let me know what actually runs over Muen SK in >> Genode base-hw kernel VM. Does it mean we run another kernel like nova >> between Muen and virtualbox. >> >> I really like the idea but if we have another kernel below virtualbox >> than why not run virtualbox on Muen as a subject? I am unable to criticize >> clearly due to the mentioned confusion. >> >> Thanks. >> >> Regards, >> Shahbaz >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> genode-main mailing list >> genode-main(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/genode-main >> >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > genode-main mailing list > genode-main(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > > -- Shahbaz Khan

2 3

Ideas about interactive GUI
by Boris Mulder 15 Apr '17

15 Apr '17

Dear Genode Community, We have been brewing on the best way to implement an interactive menu interface. We would like to hear your opinions and ideas on this. Currently, only launcher provides this functionality. However, we had the following objectives in mind: - Decouple the menu state and the functionality. We think the menu should only be responsible for rendering the dialogs and registering input events. Whatever functionality is to be invoked based on this input should be delegated to other components. - Have a fully customizable menu. The model of what buttons and (nested) submenus exist should be configurable, and should be separated from the layout (such as how a button looks like) and from the current state (which menus are collapsed, etc). In order to shape this, we have the following ideas: - The configuration of the menu model can be specified in XML in its config, and be reconfigurable at runtime. Parts of this could be defined by other components as well. Examples of how this could look like is described in the attached xml file. - Events related to the menu either trigger menu actions (in which case the config dictates the proper response, such as showing or hiding a submenu) or trigger external actions. In the second case, the menu generates a report that for instance states a certain button has been clicked. Again, see the attachment. - Any (custom) component can read these reports and take certain actions. For example, in case programs are to be started with the menu, we can add an init component that takes its config from another rom module. A subsystem management component containing a more extensive state model would read the events from the menu, change init's config based on this, and monitor the state of started subsystems and perhaps add extra context menus for these subsystems. Another example is a shutdown button that talks to a component that can write the system state, and which could show a dialog with the options to power off or reset a systems. Perhaps it can try to gracefully stop running programs with disk state (such as virtualbox) by talking with the subsystem manager as explained above. In any case, the menu should be able to support any functionality by providing a generic interface to components such as the examples above. - The layout of the menu can be specified in the config as well, perhaps using (a subset of) CSS, or as it is now, with the styles database that contains pictures for each element. (buttons, bars, etc.) While looking at ways to implement this, we also encountered the following problems: -As it is currently with launcher, a lot of subsystem functionality is intertwined with the interactive menu. This makes implementing such a modification a bit more difficult than replacing the subsystem management part with a reporting part. One of the issues we face is that showing and hiding windows of other components is done through the session_control function in the nitpicker session interface, but this is limited to the session of the components and its children. Children of an init component therefore cannot be affected. One way to fix this is to add a policy in the window manager or nitpicker that allows the menu or some other component to execute session_control on certain or all sessions. Implementing session_control functionality in init itself does not look like a clean solution. Another issue is that init does not keep track of exited children. Launcher neatly closes the corresponding menu entries by installing a signal when the child exits, but init does not have such functionality now. Perhaps init could be modified such that it generates a report when a child exits? For now, if we would quit a child with another method than through the menu, we have no way of knowing if a child exited. I'd very much like to hear your comments on these ideas and on the best way to realize it (perhaps together), and for instance how you think we could resolve the above issues. -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users