users January 2013

users@lists.genode.org

30 participants
52 discussions

What is going on for february release?
by Paul Dufresne 20 Feb '13

20 Feb '13

Well, february 2013 is at our door now, and I would like to remember us of the plan for it according to our 2013 roadmap: -Low-latency audio support The current audio_out-session interface was our first shot into the direction of audio processing. To enable use cases where streaming audio and sporadic sounds must be accommodated at the same time, we need to revise our approach. -IOMMU support on NOVA -First steps of user-interface concept --UI concept for pleasant working environment --Tiled window manager --Terminal improvements (e.g., scroll buffer) --Noux improvements (e.g., signals) -Improved x86 virtualization support --Improved virtualization support (Vancouver on NOVA) I'd like to have a small picture of who is working on what in the previous list. And the current status of things.

3 3

Looks like unnecessary mapping of capability
by jaeyong yoo 03 Feb '13

03 Feb '13

Hello! Genode, >From time to time, I saw something like this: l4_task_map(L4_BASE_TASK_CAP, L4_BASE_TASK_CAP, l4_obj_fpage(A.dst(), 0, L4_FPAGE_RWX), B.dst() | L4_ITEM_MAP); I think it looks like a unnecessary mapping, because rather than mapping, we can just copy the capability like this, A = B. Since I'm feeling like I miss something here, could you tell me the difference between two of them? Best regards, Jaeyong

2 6

Hacking core to pass base capabilities.
by Daniel Waddington 01 Feb '13

01 Feb '13

Hi, I am trying to hack Genode's core so that either init, or a child of init, is given the L4_BASE_ICU_CAP. This will allow (as a hack) direct handling of IRQs from the kernel. My problem is, is that I cannot see how to get the native task cap (relevant to the parent process) for the child process (e.g., from the Core_child or Child class) in order to do the task map. Can someone give me some hints? Sorry to be hacking your beautiful design ;) and yes, I know this is bad from a security perspective. Daniel

2 2

[Genode] Possibility of genode capability-selector conflict while thread creation in Fiasco.OC
by jaeyong yoo 31 Jan '13

31 Jan '13

Hello, genode! In Thread_base::start() function, there is a capability inserting part: Cap_index *i = cap_map()->insert(state.id, state.cap); l4_utcb_tcr_u(state.utcb)->user[UTCB_TCR_BADGE] = (unsigned long) i; l4_utcb_tcr_u(state.utcb)->user[UTCB_TCR_THREAD_OBJ] = (addr_t)this; in the above, *state.kcap* is the cap-selector in the Genode CORE (where Cpu_root is there). And, Thread_base::start() function tries to create the capability with the same value of state.kcap (it looks rather than delegating, uses direct value). My question here is that, "could it be possible that the state.kcap value is already taken by some other capability in the Genode application?" Best regards, Jaeyong

2 1

A question regarding thread creation in L4Linux.
by Сергей Грехов 31 Jan '13

31 Jan '13

Hello to everyone! The question is about method l4lx_thread_create() from ports-foc/src/lib/l4lx/l4lx_thread.cc. According to the thread creation procedure in L4lx library, the pointer to VCPU instances are saved in a static array static L4lx::Vcpu* vcpus[L4LX_THREAD_NO_THREADS]; The index within this array is defined by passing UTCB address to function thread_id(). Now, if enable SMP and set two VCPUs, one can see the following strange thing: //creating cpu0 l4lx_thread_create: (vc->utcb() = 44000400) thread_id() = 00000002 TID = 00011000 //everything is fine: pointer to Vcpu instance is saved under id=2 //creating timer l4lx_thread_create: (vc->utcb() = 44000600) thread_id() = 00000001 TID = 00015000 //everything is fine here too: pointer to Vcpu instance is saved under id=1 //creating cpu1 l4lx_thread_create: (vc->utcb() = 44000800) thread_id() = 00000002 TID = 00019000 //something weird is happening here: pointer to Vcpu instance is saved under id=2, previous pointer is lost. Looking inside thread_id() one can find that it uses utcb_base_addr() [which is equal to l4_utcb()] to calculate required index in array. Is it a bug? Should not the utcb_base_addr() be something similar to following expression: (Genode::Native_config::context_area_virtual_base() + THREAD_MAX * Genode::Native_config::context_virtual_size()) ? -- Best regards, Sergey S. Grekhov

2 1

[genode] Label in l4_ipc_wait
by jaeyong yoo 31 Jan '13

31 Jan '13

Hello Genode, I have a question regarding Genode Label in Fiasco.OC kernel. I noticed that Msgbuf_base::label() is the same as the return value of l4_ipc_wait (which is basically genode label): L4_INLINE l4_msgtag_t l4_ipc_wait(l4_utcb_t *utcb, l4_umword_t *label, l4_timeout_t timeout) L4_NOTHROW; label is described as following: * \retval label Label assigned to the source object (IPC gate or IRQ). But, I can not see any corresponding label in ipc call as we can see below: L4_INLINE l4_msgtag_t l4_ipc_call(l4_cap_idx_t object, l4_utcb_t *utcb, l4_msgtag_t tag, l4_timeout_t timeout) L4_NOTHROW; So, here goes the question: Since genode label is passed to the first data of Msgbuf_base::buf, does Fiasco.OC pickup this value and return when l4_ipc_wait function called? Best regards, Jaeyong

2 2

Re: build directory outside of Genode dir xor vim error
by unknown＠example.com 31 Jan '13

31 Jan '13

"Or alternatively, how about taking the lack of nano as a wonderful opportunity to learn (and learn loving) vim, hehe... :-)" I (nano nano) agree. > ----- Original Message ----- > From: Norman Feske > Sent: 01/28/13 09:06 AM > To: genode-main(a)lists.sourceforge.net > Subject: Re: build directory outside of Genode dir xor vim error > > Hi Paul, > > > First change: staging rather than master. > > this is not recommended. We often change the commits that are on staging > but not yet merged into master. Hence, using staging will be pretty > messy on your side. If you like to use a particular commit that is only > available on staging, better create a new branch of master and > cherry-pick the single commit: > > git checkout -b <name-of-your-branch> genodelabs/master > git cherry-pick <commit-id> > > > Second change: try make run/noux_bash > > > > Third change: > > ./tool/create_builddir linux_x86 BUILD_DIR="./build.lx" > > rather than the usual: > > ./tool/create_builddir linux_x86 BUILD_DIR="build.lx" > > Both variants should work. I just tried them - they produce exactly the > same build directory. > > > About third change, result in make run/noux_bash to: > > Program core/core > > make[1]: Leaving directory `/home/paul/build.lx' > > genode build completed > > I think you missed some steps that are needed prior running the > run/noux_bash.run script. > > First, can you check that you enabled the 'libports', 'ports', and > 'gems' repositories in your '<build-dir>/etc/build.conf' file? > > You will also need to download several 3rd-party source codes in > 'libports' and 'ports' respectively. I guess that the build system has > printed a couple of messages like the following, has it? > > Skip target noux-pkg/bash because it requires prepare_bash > Skip target noux-pkg/coreutils because it requires prepare_coreutils > Skip target noux-pkg/vim because it requires prepare_vim > > These messages indicate that the said 3rd-party codes are not available. > To rectify the problem, please issue the following commands: > > cd <genode-dir>/ports > make prepare PKG='bash coreutils vim' > > You will also need to download some code in libports, i.e., the libc and > ncurses: > > cd <genode-dir>/libports > make prepare PKG='libc ncurses' > > > find: `bin/coreutils/': No such file or directory > > That is because of the missing 'make prepare' steps mentioned above. > > > couldn't open "bin/vim/share/vim/vimrc": no such file or directory > > When built successfully, the so-called noux packages (such as coreutils, > bash, and vim) will end up being installed at > '<build-dir>/bin/<noux-package-name>'. Because the build system skipped > those packages in your case, these directories do not exist. However, > the run script expects them to be present after having completed the > build step. When it tries to generate a vimrc file at the > '<build-dir>/bin/vim/share/vim/vimrc', it fails because the surrounding > directory does not exist. > > Maybe it would be a good idea to let the run script detect this > condition and print a more meaningful error message? > > > I need my own vim configuration file? > > The run script generates a vim configuration file for you. > > > I am not too used to vim... I prefer nano. > > The 'noux_bash.run' script generates a system that consists only of > coreutils, bash, and vim. It is just an example and is meant as a > starting point for creating customized systems. For example, the > noux_tool_chain* scripts describe much more sophisticated system > scenarios including gcc and binutils. > > There is currently no noux package for nano. So you would need to port > nano first before being able to integrate it. If you like to give it a > try, look for the way how a simple noux package such as GNU make is > integrated in the 'ports' repository. Depending on the package, the > porting work may involve slight refinements of the libc or noux, or will > even require you to port additional libraries first. Of course, you will > also need to modify the run script accordingly. You are welcome to give > it a shot. > > Or alternatively, how about taking the lack of nano as a wonderful > opportunity to learn (and learn loving) vim, hehe... :-) > > 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 > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > Genode-main mailing list > Genode-main(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main >

5 13

Signal_dispatcher & base-hw
by Martin Stein 30 Jan '13

30 Jan '13

If i didn't misunderstood the function of 'Signal_dispatcher' it should be provided through a separate header. This is because 'base-hw' implements the basics of 'base/signal.h' (Signal, Signal_receiver, Signal_context, Signal_transmitter) by itself, to optimize the code via specific kernel-mechanisms. But there seems to be no need to add a specific implementation of 'Signal_dispatcher' because it only . Am i right?

2 1

debug vs. release
by Daniel Waddington 30 Jan '13

30 Jan '13

Hi, Does the Genode build system have support for debug vs. release build differentiation? Are there conventions for code-level conditionals? If not, I suggest you the Genode folks might consider adding to the road map. Daniel

2 1

[Genode] why do I need to rebuild ports for different platforms? was: buid directory outside ...
by Paul Dufresne 29 Jan '13

29 Jan '13

I said: --- While trying the different 'platforms' (kernels), the build system seems a bit unoptimized. To me, rebuilding libports, ports, gems in each different kernels don't make much sense. I don't expect them to apply patch platform-specifics, only Genode-specifics. So it would make sense to specify two directory on create_builddir: one common for all platforms, and one for the platform. --- Norman replied: That would be cool but it is not possible. Even though those libraries look like being the same for each base platform, they are different. At compile time, those libraries ultimately depend on platform-specific header files (e.g., the kernel's syscall bindings). So a library built for one kernel will typically not work on another kernel because it would try to call kernel functions in wrong ways. In theory, all those kernel-specific things could be encapsulated in a single kernel-specific library with an interface that hides all kernel details. But in practice, this would be extremely difficult and the extra indirection needed for that would certainly imply runtime overheads. In my opinion, the little added value of such a feature does not justify opening a big can of problems. --- Strange. You made me think if I expect libc to be differently compiled for different platforms. I concluded that I don't expect so. In fact I expect everything running above Core, to not be platform-specific, including device drivers. Sure, we don't need to build some drivers if the architecture does not have the coresponing hardware, but that does not means it would be compiled differently. And I definitively *do not* expect libraries to be compiled with specific kernel headers file. I expect libc, device drivers, to call Core the same way, and Core to be compiled in a specific manner for each platform.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users January 2013