gmane.comp.micro-kernel.l4.devel

Using pthread on L4/Fiasco

석현철 — 2012-05-23T09:13:00

Thank you.

 

I made a stupid mistake.

 

When I added “REQUIRES_LIBS = libpthread” into Makefile, I modified three
Makefiles.

There are hello/Makefile, hello/server/Makefile, and
hello/server/src/Makefile.

 

I tested one by one.

But I found I made a mistake.

At last try, I wrote REQUIRES = libpthread instead of REQUIRES_LIBS =
libpthread on hello/server/src/Makefile.

 

After correcting my mistake, I can test pthread application.

 

Thank you! Marcus

 

Hyunchul Seok.

 

_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Using pthread on L4/Fiasco

Marcus Haehnel — 2012-05-23T08:08:29

Hi,

Am 2012-05-23 09:01, schrieb 석현철:

The error message has nothing to do with the header, as it is an error 
in the link phase, where the symbols of the libpthread can not be 
resolved.



Yes, you need to include this line in your Makefile and for me this 
leads to the program linking correctly.
Are you sure you included it in server/src/Makefile and not somewhere 
else? Can you show us your Makefile and the Output of

make V=1

to see the compiler and linker commands invoked?




Kind regards,

Marcus



_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Using pthread on L4/Fiasco

석현철 — 2012-05-23T07:01:41

Hi. Hackers

 

I’m trying to use pthread in an application which runs on L4.

I modified “main.c” in Hello application, including “#include
<pthread.h>”.

And when I compiled L4Re, I got error messages:

 

 

main.o: In function `main':

/root/l4re-core-2011081207/src/l4/pkg/hello/server/src/main.c:39: undefined
reference to `pthread_create'

/root/l4re-core-2011081207/src/l4/pkg/hello/server/src/main.c:44: undefined
reference to `pthread_join'

make[5]: *** [hello] Error 1

 

 

I think this is because it cannot fine pthread.h header file. But I don’t
know how to fix it.

 

When I looked up previous lists, I could find one thread related to pthread
in 2011 list.

(the thread title is “Silly Pthread Issues”)

I think that it is the same problem, but the reply is only one. Said “Add
REQUIRES_LIBS = libpthread to the Makefile.”

Actually, I tried it, but I couldn’t solve the problem.

 

How can I use the pthread? Please, Help me!!

 

Thank you!

Hyunchul Seok

 

 

 

The modified

[l4ankh] Problems with fixed l4ankh

Timur — 2012-05-22T17:16:39

Hi!
I had fixed the l4ankh driver and after that it started to work properly. Now 
only thread is used to receive packets. In lines 158-162 we clear the rcv 
buffer: that is necessary to be done as after opening a session we start to 
receive packets that should not be served; otherwise the response time will be 
quite slow. This is not the best solution, but I do not have time to make it 
better.
Now I face the following problem: the driver in ankh (I use 8139cp) stops 
receiving packets after some time (for me it is usually 3-4 minutes). This 
situation occurs when  the interrupt handler was called and the device 
register IntrStatus already equals "zero". An interrupt doesn't work after 
that.

Re: [Announcement] Karma VMM first public release

Norman Feske — 2012-05-18T07:00:41

Hi Steffen,

thank you for the elaborate reply! The text you have just written would
fit pretty well on karma-vmm.org, doesn't it?. .-)


I am far from being proficient when it comes to Afterburner but from
what I understand so far, there seem to be quite a few similarities
between this project and the approach you have taken with Karma.
Code-wise, the Afterburner VMM (called wedge) is cleanly separated from
the Linux kernel. The fact that its code is executed in the same address
space as the Linux kernel rather than a different address space (as in
Vancouver and Karma) is just a performance optimization.

The list of interface functions provided by the wedge is illustrative:


https://github.com/l4ka/afterburner/blob/master/afterburn-wedge/ia32/vmiCalls.h

Most of those functions are concerned with low-level CPU emulation. In
the original form of Afterburner, they are invoked by little code stubs
that replace their corresponding CPU instructions by upcalls to the
wedge. (the replacement of those the critica

Re: [Announcement] Karma VMM first public release

Steffen Liebergeld — 2012-05-16T10:29:05

Hi Norman, L4 Hackers,

let me try to clarify what Karma is by giving an very short overview on
L4Linux, Afterburner and Vancouver.

L4Linux is a port of the Linux kernel to the microkernel API. In this
setup Linux runs in its own address space as an L4 task. Its
applications also reside in L4 tasks that reside beside L4Linux. This
setup requires in depth modification to the Linux kernel, and -due to
the increased number if context switches- has an inherent performance
penalty. L4Linux runs on platforms that are not virtualizable (e.g. ARM,
x86). It uses the L4Re infrastructure to implement peripheral devices,
such as framebuffer, shared memory network interface and device discovery.

As far as I know, Afterburner also runs OS kernels on top of a
microkernel on platforms that are not virtualizable. Hereby the guest
kernel binary is modified to replace virtualization sensitive
instructions with "hypercalls". The "hypervisor" resides in the same
address space as the guest kernel, and implements an emulation fo

Re: [Announcement] Karma VMM first public release

Norman Feske — 2012-05-16T09:15:45

Hello,

congratulations for getting Karma out of the door finally. :-)

The project looks very interesting. However, I think it would be
sensible of you to contrast your approach with existing projects, in
particular L4Linux, Afterburner, and Vancouver. This way, potential
users would gain a better understanding of the incentive behind Karma.

From what I gathered from personal conversations with you:

 * Karma has a higher performance than L4Linux.
 * The VMM runs outside of the Linux kernel similar to Afterburner.
 * The patch against the vanilla Linux kernel is much simpler and
   trivial to maintain compared to the L4Linux kernel. (similar to
   Afterburner)
 * Karma has no ambition to become a VMM with support for faithful
   virtualization. Hence, running Windows on Karma won't be possible.
 * Because Karma depends on x86 H/W-virtualization support, the
   approch cannot be used on ARM for now.

Are these assumptions valid?

Again, thanks for sharing your work with the community. I'm looking
forward to

Re: Booting L4/Fiasco + L4Re on PC

Matthias Lange — 2012-05-16T06:56:33

Just burn the image to a CD and boot your PC from CDROM.

Matthias.

Booting L4/Fiasco + L4Re on PC

석현철 — 2012-05-16T05:59:54

Hello.

 

I’ve tried to boot L4/Fiasco on PC.

 

I followed the directions for building from both “http://os.inf.tu-dresden.
de/fiasco/build.html” and “http://os.inf.tu-dresden.de/L4Re/build.html”

And I could run L4/Fiasco on QEMU.

 

Now I hope I want to boot L4 on PC environment.

As I searched, it can be done through GRUB. (But, I am not convinced that
it is right way.)

Anyway, I’ve tried to boot L4 by using GRUB.

 

I use Ubuntu Linux for compiling L4/Fiasco and L4Re. In this, there is
GRUBv2.

 

I made the bootable ISO image.

(It is done by “make grub2iso E=hello MODULE_SEARCH_PATH={mypath}”)

 

And then, what should I do in order to boot L4 on PC?

 

How should I configure the GRUB configuration?

 

I really want to know how to boot L4 on PC. Please, help me!

 

 

Kind Regards,

Hyunchul Seok.

 

 

_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: understanding l4re

Björn Döbel — 2012-05-14T22:02:08

Hi,

On 14.05.2012 18:13, Ryan Brown wrote:

No. These docs don't describe the Fiasco.OC API (although many of the 
concepts are shared). The relevant documentation for Fiasco and the L4 
Runtime Environment is at https://os.inf.tu-dresden.de/L4Re/doc/

(yes, that's all for now - if you have any questions, please ask and 
we're glad to help). There's also a Wiki: http://wiki.tudos.org/Main_Page


As in any other system, pthread_create() returns -EAGAIN if there are 
insufficient system resources to create another thread. This may happen, 
if the lib is not able to allocate a stack or TLS area for the thread or 
in the Fiasco.OC case if there are insufficient kernel resources.


Actually, scheduling is the only policy that is implemented in the 
kernel and as far as I know most L4 variants do this, although there 
have been experiments to do it in user space. [1]


Fiasco.OC schedules threads based on their priorities. (Same priority 
leads to round-robbin scheduling.) There are separate run queues for 
every

Re: [Announcement] Karma VMM first public release

Julian Stecklina — 2012-05-14T21:20:43

On Mon, 2012-05-14 at 17:59 -0300, John van V. wrote: 

Can you elaborate on that?

Julian

Re: [Announcement] Karma VMM first public release

John van V. — 2012-05-14T20:59:58

Why not just let go of the linux and run posix w/ gcc?  And make a
windows-friendly driver conversion kit?

On Mon, May 14, 2012 at 6:44 AM, Matthias Lange
<mlange< at >sec.t-labs.tu-berlin.de> wrote:

[Announcement] Karma VMM first public release

Matthias Lange — 2012-05-14T09:44:34

We are happy to announce the first public release of the Karma Virtual
Machine Monitor [0].

Karma is a virtual machine monitor (VMM) that runs Linux in a virtual
machine on top of the Fiasco.OC [1] microkernel. Its main design
directives are speed and simplicity. Unlike KVM, VirtualBox or VMWare,
Karma does no emulation, but resorts to aggressive paravirtualization
and therefore has low complexity and shows superior performance for a
number of benchmarks.

Karma requires hardware assisted CPU virtualization. A feature that is
available on all recent x86 CPUs (SVM or VT). Optionally, it can make
use of hardware assisted memory virtualization (Nested Paging or ePT),
if available.

The Karma VMM is currently being used as a research vehicle at
Technische Universität Berlin and Technische Universität Dresden.

It main features are:
- Trustworthy isolation of virtual machines by means of the microkernel.
  VMM compromise does no harm to other virtual machines as one instance
  of Karma runs exactly one virtual

Re: IGB driver not getting Rx interrupt

Julian Stecklina — 2012-05-13T22:08:02

On Sun, 2012-05-13 at 23:53 +0200, Adam Lackorzynski wrote: 

For IGB that register would be called ICR or EICR (interrupt cause
register). Hope that helps finding it in the source.

Julian

Re: IGB driver not getting Rx interrupt

Adam Lackorzynski — 2012-05-13T21:53:21

Hi,

On Thu May 10, 2012 at 15:14:47 -0700, Shashi Sharma wrote:

Ok.


Usually a device has a device register that indicates whether an
interrupt has been asserted. So in JDB you could look up the this
register, or add some printf in the driver or so to see if its contents
change after some packet transfer should have happened.



Adam

Re: Fiasco.OC on Cortex-A9

Johan Dams — 2012-05-12T19:12:12

Hi.

Ok, got it to work in Qemu with the realview-pbx-a9 target. Still
working on the problem on i.MX6. 


Best regards,
Johan

On Fri, 2012-05-11 at 20:13 +0300, Johan Dams wrote:

Re: Fiasco.OC on Cortex-A9

Johan Dams — 2012-05-11T17:13:29

Hi.

As a follow up to my email below, I compiled Fiasco for the Realview
system and ran under QEmu. This is my output:

L4 Bootstrapper
  Build: #5 Fri May 11 19:55:05 EEST 2012, 4.5.3
  Scanning up to 256 MB RAM
  Memory size is 256MB (00000000 - 10000000)
  RAM: 0000000000000000 - 000000000fffffff: 262144kB
  Total RAM: 256MB
  mod08: 011ec000-01205544: hello
  mod07: 01198000-011eb22c: ned
  mod06: 010bd000-01197b8c: io
  mod05: 010bc000-010bc016: arm-imx6.devs
  mod04: 010bb000-010bb079: startup.conf
  mod03: 010a1000-010ba45c: l4re
  mod02: 01067000-010a062c: moe
  mod01: 0105d000-01066340: sigma0
  mod00: 01014000-0105c7b0: fiasco
  Moving 9 modules to 1100000 with offset ec000
  moving module 09 { 11ec000-1205544 } -> { 12d8000-12f1544 }
  moving module 08 { 1198000-11eb22c } -> { 1284000-12d722c }
  moving module 07 { 10bd000-1197b8c } -> { 11a9000-1283b8c }
  moving module 06 { 10bc000-10bc016 } -> { 11a8000-11a8016 }
  moving module 05 { 10bb000-10bb079 } -> { 11a7000-11a7079 }
  moving module 04

Fiasco.OC on Cortex-A9

Johan Dams — 2012-05-11T14:01:29

Hi all,

I'm wondering if anyone has come across an issue with Fiasco.OC on
Cortex-A9 based systems. The problem is that I do not get past this
instruction (and with that I mean that the system just locks up): 

"mcr p15, 0, %[control], c1, c0 \n" // control

in src/kern/arm/bootstrap.cpp. The exact same code works fine on a
Cortex-A8 based processor. Changing cache on or off (in the control
variable) does not change anything. Also, just reading the current
content of the register and writing it back locks the system.

I have been going over compiler flags, tried different compilers
altogether (using 4.5.3-r1 right now), and looked if something odd was
going on with the generated assembly code, etc. with no results.

This code is a standard ARM instruction, and comes well before any
paging or even the actual kernel starts.

The SOC in question is a Freescale i.MX6 Quad core Cortex A9, which I
realize not many have actually used yet. However, if similar issues
presented itself on other platforms, these might

Re: understanding l4re

Björn Döbel — 2012-05-11T14:06:57

Hi Ryan,

On 11.05.2012 03:15, Ryan Brown wrote:

Note, that not all files in uClibC are built. Instead, we only compile
a subset that is semi-magically determined by the list in
l4/pkg/uclibc/lib/uclibc/contrib_files.mk. Basically, you can
distinguish two classes of files:

a) files that don't have dependencies on the underlying system or
platform -- those are taken from the original uClibC sources in
l4/pkg/uclibc/lib/contrib

b) files that depend on system calls and other infrastructure (e.g.,
file systems) -- those either come from our own implementation
(l4/pkg/uclibc/lib/uclibc/*) or from the libc_backends package.

Anything related to making system calls falls under category b) and of
course uses Fiasco system calls.


There are a couple of backends in l4/pkg/libc_backends. For instance
l4/pkg/libc_backends/lib/sig implements POSIX signals on top of L4. You
will notice that it uses Fiasco system calls (look for functions
starting with l4_*()).

The backend idea is: every backend implements a part of P

understanding l4re

Ryan Brown — 2012-05-11T01:15:01

Hi. I'm exploring developing software that runs on Fiasco.OC/L4re, so I'm
trying to understand how the various pieces fit together.  If I'm following
the makefiles correctly it looks like some uclibc files (like libc/inet)
are getting compiled, but they seem to be making linux system calls. I also
see the libc_backends code, and I'm not sure how this fits in. It looks
like these are mostly stubs, is it expected that you'll link the final
binary with the real implementation you want?

I also took a look at libpthreads, and I don't see much l4 specific code.
It looks like mutexes are implemented as spinlocks? Isn't there a better
way to do synchronization in fiasco?
_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: IGB driver not getting Rx interrupt

Shashi Sharma — 2012-05-10T22:14:47

Hi Adam,

I am pretty sure now that Fiasco's ISR is not getting invoked. I put a
printf in the following interrupt handler in fiasco's
src/kern/ia32/dirq-ia32-ux.cpp.

----
extern "C" FIASCO_FASTCALL
void
irq_interrupt(Mword _irqobj, Mword ip)
----------

And it never gets invoked.

You suggested in your last e-mail to "check whether the card is
reporting a pending interrupt". But I dont really know how to do that.
Is there some way in JDB to do that?

Regards,
Shashi Sharma

On Mon, 2012-05-07 at 00:09 +0200, Adam Lackorzynski wrote: