Nabble - l4ka project

RE: UTCB-Area, Local ThreadIds

2009-12-16T09:36:10Z

> 1: Is there a way, to get the address of a UTCB area of an address space or do
> I have to store/remember it after creation of the address space?
> I've read there is just a hack with MyLocalId() to get the UTCB area of the
> root-task. Is that a technical issue or shouldn't I just get it?

You have to remember it afaik. It's not a technical issue, it's just that user can keep it w/o problems and the kernel doesn't need another interface then.

> 2: In which parts of the memory I am generally allowed to write after startup,
> without accidently overwriting important data? Do I have the entire Virtual
> Memory? Here is a part of my KIP:

So conceptually, you should write into virtual address area backed with normal physical memory, since all other areas have special semantics. Sigma0 helps you a little bit there, since it's implemented in a way that it hands out normal memory on page faults but wants to be asked explicitly (via IPC) for handing out non-memory areas (architecture specific, device mem, ...).

-Jan
--
Jan Stoess
KIT/UKa System Architecture Group
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

> -----Original Message-----
> From: l4ka-bounces@... [mailto:l4ka-bounces@...-
> karlsruhe.de] On Behalf Of Martin
> Sent: Saturday, December 12, 2009 8:59 PM
> To: l4ka@...
> Subject: UTCB-Area, Local ThreadIds
>
> Hello,
>
> I don't have so much experience with the L4-Kernel yet and got some
> Questions. I am working on IA32 and Kernel-Verion 0.4.0:
>
> 1: Is there a way, to get the address of a UTCB area of an address space or do
> I have to store/remember it after creation of the address space?
> I've read there is just a hack with MyLocalId() to get the UTCB area of the
> root-task. Is that a technical issue or shouldn't I just get it?
>
> 2: In which parts of the memory I am generally allowed to write after startup,
> without accidently overwriting important data? Do I have the entire Virtual
> Memory? Here is a part of my KIP:
>
> Memory regions (17):
> Physical: 0x00000000 - 0xffffffff shared
> 0x00000000 - 0x0009efff conventional
> 0x0009f000 - 0x0009ffff architecture specific (2)
> 0x000e8000 - 0x000fffff architecture specific (2)
> 0x00100000 - 0x07feffff conventional
> 0x07ff0000 - 0x07ffffff architecture specific (3)
> 0xfffbc000 - 0xfffbffff architecture specific (2)
> 0xfffc0000 - 0xffffffff architecture specific (2)
> 0x06ff0000 - 0x07feffff reserved
> 0x000a0000 - 0x000bffff shared
> 0x000c0000 - 0x000effff shared
> 0x00020000 - 0x000297ff bootloader specific (2)
> 0x00300000 - 0x003037ff bootloader specific (2)
> 0x00001000 - 0x00001fff bootloader specific (1)
> 0x00002000 - 0x00002fff bootloader specific (1)
> 0x00100000 - 0x00141fff reserved
> Virtual: 0x00000000 - 0xbfffffff conventional
>
> Memory regions:
> Main mem 0x00000000 - 0x00000000
> Reserved mem0 0x00100200 - 0x00142000
> Reserved mem1 0x00000000 - 0x00000000
> Dedicated mem0 0x00000000 - 0x00000000
> Dedicated mem1 0x00000000 - 0x00000000
> Dedicated mem2 0x00000000 - 0x00000000
> Dedicated mem3 0x00000000 - 0x00000000
> Dedicated mem4 0x00000000 - 0x00000000
>
>
> Where is the root-tasks data? Is it in the Reserved mem0?
>
>
> 3: How do I set/manipulate local ThreadIds? ThreadControl() is just working
> with global IDs. After creation of Threads, all local IDs are 0, this shouldn't be,
> right?
>
>
> Thank you very much,
> Gnuffel
> --
> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

From forum: l4ka@ira.uni-karlsruhe.de

RE: Building a working instance of L4Ka::Pistachio

2009-12-16T09:36:09Z

Hard to tell what the real problem might be. Can you, since this is the simplest check, build pistachio with an older compiler? New compiler and binutils versions sometimes cause headaches, and I’ve not checked build against newer versions for quite some time. You can find a list of known-working compilers here:

http://l4ka.org/projects/pistachio/buildstatus/hg.php

-Jan

Jan Stoess

KIT/UKa System Architecture Group

Phone: +49 (721) 608-4056

Fax: +49 (721) 608-7664

eMail: stoess@...

From: l4ka-bounces@... [mailto:l4ka-bounces@...] On Behalf Of Owen Shepherd
Sent: Thursday, December 03, 2009 7:45 PM
To: l4ka@...
Subject: Building a working instance of L4Ka::Pistachio

OK, I'm currently attempting to build Pistachio for x86 32-bit. I've built a pretty standard kernel (Pentium 2/3, KDB, spinwheels and tracing are the only things I've enabled for now). My aim is an AMD64 kernel with more features, but it's always best to start with a smaller base and get that working first.

I've then built the usermode tasks, and built a grub disk using the included grubdisk.img. Problem is, the kernel crashes on both emulators I've tried it with (Bochs and QEMU).

The last message I get from the kernel before it crashes is "Initializing GDT (Preliminary)". The Bochslog preceding this is

00128039070e[CPU0 ] LTR: doesn't point to an available TSS descriptor!

00128039070e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)

00128039070e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)

00128039070i[CPU0 ] CPU is in protected mode (active)

00128039070i[CPU0 ] CS.d_b = 32 bit

00128039070i[CPU0 ] SS.d_b = 32 bit

00128039070i[CPU0 ] EFER = 0x00000000

00128039070i[CPU0 ] | RAX=000000000000f012 RBX=00000000000000f0

00128039070i[CPU0 ] | RCX=0000000000000f00 RDX=0000000000000000

00128039070i[CPU0 ] | RSP=000000000015648c RBP=0000000000802028

00128039070i[CPU0 ] | RSI=000000000000df00 RDI=000000000003eaa0

00128039070i[CPU0 ] | R8=0000000000000000 R9=0000000000000000

00128039070i[CPU0 ] | R10=0000000000000000 R11=0000000000000000

00128039070i[CPU0 ] | R12=0000000000000000 R13=0000000000000000

00128039070i[CPU0 ] | R14=0000000000000000 R15=0000000000000000

00128039070i[CPU0 ] | IOPL=0 ID vip vif ac vm RF nt of df if tf sf zf af PF cf

00128039070i[CPU0 ] | SEG selector base limit G D

00128039070i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D

00128039070i[CPU0 ] | CS:0008( 0001| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | DS:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | SS:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | ES:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | FS:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | GS:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | MSR_FS_BASE:0000000000000000

00128039070i[CPU0 ] | MSR_GS_BASE:0000000000000000

00128039070i[CPU0 ] | RIP=00000000001532dc (00000000001532dc)

00128039070i[CPU0 ] | CR0=0xe0010011 CR2=0x0000000000000000

00128039070i[CPU0 ] | CR3=0x00134000 CR4=0x00000090

(0).[128039070] [0x001532dc] 0008:00000000001532dc (unk. ctxt): ltr word ptr ss:[esp+0x10] ; 0f005c2410

00128039070e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

I think we can safely assume that something has gone wrong loading the TSS, a general protection fault has been raised during the LTR, then a double fault has followed that.

Is this a bug in the L4 sources, or an issue with my build environment? The important information is

$ uname -a

Linux sidewinder 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009 x86_64 GNU/Linux

$ gcc -v

Using built-in specs.

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix

gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8)

$ ld -v

GNU ld (GNU Binutils for Ubuntu) 2.20

From forum: l4ka@ira.uni-karlsruhe.de

UTCB-Area, Local ThreadIds

2009-12-12T11:58:51Z

Hello,

I don't have so much experience with the L4-Kernel yet and got some Questions. I am working on IA32 and Kernel-Verion 0.4.0:

1: Is there a way, to get the address of a UTCB area of an address space or do I have to store/remember it after creation of the address space?
I've read there is just a hack with MyLocalId() to get the UTCB area of the root-task. Is that a technical issue or shouldn't I just get it?

2: In which parts of the memory I am generally allowed to write after startup, without accidently overwriting important data? Do I have the entire Virtual Memory? Here is a part of my KIP:

Memory regions (17):
Physical: 0x00000000 - 0xffffffff shared
0x00000000 - 0x0009efff conventional
0x0009f000 - 0x0009ffff architecture specific (2)
0x000e8000 - 0x000fffff architecture specific (2)
0x00100000 - 0x07feffff conventional
0x07ff0000 - 0x07ffffff architecture specific (3)
0xfffbc000 - 0xfffbffff architecture specific (2)
0xfffc0000 - 0xffffffff architecture specific (2)
0x06ff0000 - 0x07feffff reserved
0x000a0000 - 0x000bffff shared
0x000c0000 - 0x000effff shared
0x00020000 - 0x000297ff bootloader specific (2)
0x00300000 - 0x003037ff bootloader specific (2)
0x00001000 - 0x00001fff bootloader specific (1)
0x00002000 - 0x00002fff bootloader specific (1)
0x00100000 - 0x00141fff reserved
Virtual: 0x00000000 - 0xbfffffff conventional

Memory regions:
Main mem 0x00000000 - 0x00000000
Reserved mem0 0x00100200 - 0x00142000
Reserved mem1 0x00000000 - 0x00000000
Dedicated mem0 0x00000000 - 0x00000000
Dedicated mem1 0x00000000 - 0x00000000
Dedicated mem2 0x00000000 - 0x00000000
Dedicated mem3 0x00000000 - 0x00000000
Dedicated mem4 0x00000000 - 0x00000000

Where is the root-tasks data? Is it in the Reserved mem0?

3: How do I set/manipulate local ThreadIds? ThreadControl() is just working with global IDs. After creation of Threads, all local IDs are 0, this shouldn't be, right?

Thank you very much,
Gnuffel
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

From forum: l4ka@ira.uni-karlsruhe.de

Re: L4 microkernel as a user-level program

2009-12-12T06:51:39Z

I was thinking an interesting project would be to get L4 ported to vx32. vx32 is a really lightweight virtualization environment that runs on top of Mac OS X, Linux and FreeBSD, and one of the authors actually ported the Plan 9 operating system to it, and it's bundled with the vx32 source code.

In fact, I thought it'd be good to port Plan 9 to L4 and L4 to vx32, then L4 linux could supply device drivers to Plan 9 :-).

This would satisfy some very practical goals for a somewhat small community as well as be a nice platform to build and run both L4 and Plan 9 programs without having to use a full fledged emulation environment.

vx32 can be found here: http://pdos.csail.mit.edu/~baford/vm/

(Russ Cox is one of the engineers behind Google's Go programming language, and the primary guy behind the plan 9 userspace port)

Dave

On Dec 11, 2009, at 11:00 PM, Michael FIG wrote:

> Hi,
>
> Norman Feske <norman.feske@...> writes:
>
>> there is a variant of the L4/Fiasco kernel called Fiasco UX that
>> can be executed as Linux program.
>
> Thank you very much for this pointer.
>
> I have some experience with User Mode Linux, ptrace, and other such
> black magic. IMO, it would be too much work and be of limited use to
> me to take the same approach as Fiasco UX... I am targeting multiple
> platforms (such as Windows, *BSD, Linux, and Mac OS X) and have no
> need for binary compatibility with other L4 systems.
>
> So, I'll poke around some more, and see if there is any other advice
> from people on the list. I'm thinking the best approach would be just
> to create a new architecture or two, such as "posix32", "win32", and
> write glue and stubs that is portable to many systems rather than just
> to one.
>
> By using a single-process model and thereby giving up binary
> compatibility, there is a chance of recovering high performance. My
> motivation is developing a VM for a new programming language platform.
> The language can provide some of the safety guarantees that I'll be
> losing with the single-process design.
>
> Of course, once the language gains enough applications to be useful by
> itself, I can recommend that its users install it on a "real" L4
> kernel running on bare hardware.
>
>> As far as I understand, the approach is not tied to Fiasco but could
>> be applied to Pistachio as well. If there existed a user-level version
>> of Pistachio, I'd be one of its users for sure ;-)
>
> Let me know if the above meshes with your needs!
>
> Thanks,
>
> --
> Michael FIG <michael@...> //\
> http://michael.fig.org/ \//
>

From forum: l4ka@ira.uni-karlsruhe.de

Re: L4 microkernel as a user-level program

2009-12-11T23:00:42Z

Hi,

Norman Feske <norman.feske@...> writes:

> there is a variant of the L4/Fiasco kernel called Fiasco UX that
> can be executed as Linux program.

Thank you very much for this pointer.

I have some experience with User Mode Linux, ptrace, and other such
black magic. IMO, it would be too much work and be of limited use to
me to take the same approach as Fiasco UX... I am targeting multiple
platforms (such as Windows, *BSD, Linux, and Mac OS X) and have no
need for binary compatibility with other L4 systems.

So, I'll poke around some more, and see if there is any other advice
from people on the list. I'm thinking the best approach would be just
to create a new architecture or two, such as "posix32", "win32", and
write glue and stubs that is portable to many systems rather than just
to one.

By using a single-process model and thereby giving up binary
compatibility, there is a chance of recovering high performance. My
motivation is developing a VM for a new programming language platform.
The language can provide some of the safety guarantees that I'll be
losing with the single-process design.

Of course, once the language gains enough applications to be useful by
itself, I can recommend that its users install it on a "real" L4
kernel running on bare hardware.

> As far as I understand, the approach is not tied to Fiasco but could
> be applied to Pistachio as well. If there existed a user-level version
> of Pistachio, I'd be one of its users for sure ;-)

Let me know if the above meshes with your needs!

Thanks,

--
Michael FIG <michael@...> //\
http://michael.fig.org/ \//

From forum: l4ka@ira.uni-karlsruhe.de

Re: L4 microkernel as a user-level program

2009-12-11T22:36:53Z

Hi Michael,

> I am interested in contributing to the L4 project by porting the
> microkernel interfaces to run in a simulation mode (i.e. as a regular
> application) on top of existing popular OS platforms. This would
> allow applications to migrate to using the L4 interfaces as a library
> without having to give up the amenities of their current operating
> system. The point would be to build momentum so that people write
> applications that benefit from being run on L4-based systems.
>
> Are there any people out there who are interested in this?

there is a variant of the L4/Fiasco kernel called Fiasco UX that
can be executed as Linux program. At the Dresden OS Group, it was
(and probably is) used a lot for developing user-level code. You
can find more more information at the project's website:

http://os.inf.tu-dresden.de/fiasco/ux/

I particularly recommend Udo Steinberg's studdy thesis, which offers
a great deal of technical detail:

http://os.inf.tu-dresden.de/papers_ps/steinberg-beleg.pdf

As far as I understand, the approach is not tied to Fiasco but could
be applied to Pistachio as well. If there existed a user-level version
of Pistachio, I'd be one of its users for sure ;-)

Norman

From forum: l4ka@ira.uni-karlsruhe.de

L4 microkernel as a user-level program

2009-12-11T22:16:42Z

Hi,

I'm new to the L4 world, so I'll need to learn my way around a little
before I'll be able to do much. However, I'm writing to ask about an
area that I find important for kernel adoption by application
programmers.

I am interested in contributing to the L4 project by porting the
microkernel interfaces to run in a simulation mode (i.e. as a regular
application) on top of existing popular OS platforms. This would
allow applications to migrate to using the L4 interfaces as a library
without having to give up the amenities of their current operating
system. The point would be to build momentum so that people write
applications that benefit from being run on L4-based systems.

Are there any people out there who are interested in this?

Thanks,

--
Michael FIG <michael@...> //\
http://michael.fig.org/ \//

From forum: l4ka@ira.uni-karlsruhe.de

Codezero Microkernel v0.2 Released

2009-12-07T04:54:38Z

I would like to announce that Codezero Microkernel v0.2 has been released.

On this release, the microkernel is now fully capability checked, and we
introduced the notion of containers to provide isolated execution
environments. Please see below for a brief description.

1.) Containers

In Codezero containers provide the architectural infrastructure for
isolation of execution environments. Each container is allocated with a
set of address spaces, threads, and any other resource that would
otherwise be globally available on the platform, such as virtual and
physical memory.

Using the simple notion of containers, it is possible to build any type
of software design hierarchy. A hierarchical client/server design, or
multi-threaded standalone applications are both possible scenarios.

2.) Capabilities

Capabilities protect all resources maintained by the kernel. Currently,
all system calls are protected by capabilities, except a few trivial
ones that have been left out. Physical and virtual memory, typed memory
pools, and inter-process communication are among other resources that
are protected by capability checking.

Capabilities build upon the foundation of containers, providing a
fine-grained security architecture, inside and among container boundaries.

We also introduced a capability control system call, by which the
capabilities may be shared, granted and modified in different ways,
enabling a highly flexible and configurable security architecture.

3.) Configuration

We attempted to present the above two notions in an easily manageable
kernel configuration system. Containers, their parameters and
capabilities may be adjusted easily at configuration time, using our
CML2-based kernel configuration system.

We are aiming to evolve the L4 API into the future by feedback, hence
this email post. Codezero Project is open with a GPLv3 license.

If you are interested to learn more, download by:

git-clone git://git.l4dev.org/codezero.git

A useful jump-start guide:

http://www.l4dev.org/doku.php?id=getting_started_quick

API reference man pages:

man -M codezero/docs/man pagename

Thanks,

--
Bahadir Balban

From forum: l4ka@ira.uni-karlsruhe.de

Building a working instance of L4Ka::Pistachio

2009-12-03T10:44:43Z

I've then built the usermode tasks, and built a grub disk using the included grubdisk.img. Problem is, the kernel crashes on both emulators I've tried it with (Bochs and QEMU).

The last message I get from the kernel before it crashes is "Initializing GDT (Preliminary)". The Bochslog preceding this is

00128039070e[CPU0 ] LTR: doesn't point to an available TSS descriptor!

00128039070e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)

00128039070e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)

00128039070i[CPU0 ] CPU is in protected mode (active)

00128039070i[CPU0 ] CS.d_b = 32 bit

00128039070i[CPU0 ] SS.d_b = 32 bit

00128039070i[CPU0 ] EFER = 0x00000000

00128039070i[CPU0 ] | RAX=000000000000f012 RBX=00000000000000f0

00128039070i[CPU0 ] | RCX=0000000000000f00 RDX=0000000000000000

00128039070i[CPU0 ] | RSP=000000000015648c RBP=0000000000802028

00128039070i[CPU0 ] | RSI=000000000000df00 RDI=000000000003eaa0

00128039070i[CPU0 ] | R8=0000000000000000 R9=0000000000000000

00128039070i[CPU0 ] | R10=0000000000000000 R11=0000000000000000

00128039070i[CPU0 ] | R12=0000000000000000 R13=0000000000000000

00128039070i[CPU0 ] | R14=0000000000000000 R15=0000000000000000

00128039070i[CPU0 ] | IOPL=0 ID vip vif ac vm RF nt of df if tf sf zf af PF cf

00128039070i[CPU0 ] | SEG selector base limit G D

00128039070i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D

00128039070i[CPU0 ] | CS:0008( 0001| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | DS:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | SS:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | ES:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | FS:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | GS:0010( 0002| 0| 0) 00000000 ffffffff 1 1

00128039070i[CPU0 ] | MSR_FS_BASE:0000000000000000

00128039070i[CPU0 ] | MSR_GS_BASE:0000000000000000

00128039070i[CPU0 ] | RIP=00000000001532dc (00000000001532dc)

00128039070i[CPU0 ] | CR0=0xe0010011 CR2=0x0000000000000000

00128039070i[CPU0 ] | CR3=0x00134000 CR4=0x00000090

(0).[128039070] [0x001532dc] 0008:00000000001532dc (unk. ctxt): ltr word ptr ss:[esp+0x10] ; 0f005c2410

00128039070e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

I think we can safely assume that something has gone wrong loading the TSS, a general protection fault has been raised during the LTR, then a double fault has followed that.

Is this a bug in the L4 sources, or an issue with my build environment? The important information is

$ uname -a

Linux sidewinder 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009 x86_64 GNU/Linux

$ gcc -v

Using built-in specs.

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix

gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8)

$ ld -v

GNU ld (GNU Binutils for Ubuntu) 2.20

From forum: l4ka@ira.uni-karlsruhe.de

Re: codezero community

2009-11-24T16:18:48Z

Harold Grovesteen wrote:

> Does one exist? Is there an infrastructure to actually support a
> community? The link from wikipedia gets you to a site. None of the
> links there work for the purported email list or info email. The
> contact email address for the group that appears to be supporting the
> effort, B-labs, also fails. There is supposed to be a git repository
> that I could not clone. The only success I had was downloading the v0.1
> tarball.
>
> I see in the archives an announcement for codezero. I am hoping that
> invidual will at least respond.
>
> Thanks,
> Harold Grovesteen

Harold,

There indeed is a supporting infrastructure. You've just happened to
visit our site in a bad time. We are migrating our server.

Codezero v0.2 is going to be released very soon. Meanwhile you may reach
the latest repo from git.l4dev.org

--
Bahadir Balban

From forum: l4ka@ira.uni-karlsruhe.de

codezero community

2009-11-24T12:28:57Z

Does one exist? Is there an infrastructure to actually support a
community? The link from wikipedia gets you to a site. None of the
links there work for the purported email list or info email. The
contact email address for the group that appears to be supporting the
effort, B-labs, also fails. There is supposed to be a git repository
that I could not clone. The only success I had was downloading the v0.1
tarball.

I see in the archives an announcement for codezero. I am hoping that
invidual will at least respond.

Thanks,
Harold Grovesteen

From forum: l4ka@ira.uni-karlsruhe.de

RE: Device Driver Reuse

2009-10-26T09:10:19Z

Hi Roberto,

I've added a small fix to the repo that lets the build infrastructure use gcc for all the external support stuff (e.g., dietlibc) as well. Can you please update your HG repo and tell me whether compiling dietlibc works now?

Thanks,
-Jan

--
Jan Stoess
KIT/UKa System Architecture Group
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

From forum: l4ka@ira.uni-karlsruhe.de

Re: Device Driver Reuse

2009-10-25T03:06:12Z

Hello Jan,

Thanks for your reply.

I've tried building it, but I get a

cc1: error: -mpreferred-stack-boundary=2 is not between 4 and 12

error when trying to build dietlibc. Is this error from trying to
compile it with gcc 4?

My system doesn't have gcc 3 by default, so the first make command
says that gcc 3 will be build. But when inspecting the generated
config.out with menuconfig, the build gcc option is still disabled.
Even after manually enabling it, I still get the same error.

Actually, I could manage to install gcc-3.4.6 from my distribution,
but g++ is unavailable (Ubuntu 9.4).

Is there any other tip to getting it to build?

Regards,

Roberto.

On 23/10/2009, at 20:26, Jan Stoess wrote:

> Hi Roberto,
>
> Yes there are still people (me) working on the afterburner. Mostly
> internal prototyping though, far less attention is spent to the
> external project pages.
>
> Here's a quick suggestion on getting UP afterburner/pre-
> virtualization to work (I've sent that to l4ka a while ago):
>
> - Download the afterburner via mercurial
> - No need to download pistachio or IDL tools etc., the afterburner
> make script will download it
> - check out and inspect the sample config.out files in afterburner/
> configs, e.g.,
> - choose sample-config.out if you'd like to have para-virtualized
> linux guests
> - choose sample-config-hvm.out if you'd like fully-virtualized
> guests (WARNING: WORK IN PROGRESS). Works only with Intel VMX
> - create a build directory, run "make -f path/to/afterburner/
> Makefile", copy your favorite sample config into "build/config.out",
> run "make menuconfig" to edit the settings, finally run "make
> world", which will produce binaries in "build/boot"
> - make "run-qemu" runs the afterburner in qemu
>
> Just a quick tip: use gcc and g++ Versions 3, e.g. by running make
> CC=gcc3 CXX=g++3, or by putting "CC=gcc3" and "CXX=g++3" into the
> local build Makefile.
>
> -Jan

--
Roberto Jung Drebes - Tokyo, Japan
<drebes@...>
http://japao.drebes.org/

From forum: l4ka@ira.uni-karlsruhe.de

RE: Device Driver Reuse

2009-10-23T04:26:41Z

Hi Roberto,

Yes there are still people (me) working on the afterburner. Mostly internal prototyping though, far less attention is spent to the external project pages.

Here's a quick suggestion on getting UP afterburner/pre-virtualization to work (I've sent that to l4ka a while ago):

- Download the afterburner via mercurial
- No need to download pistachio or IDL tools etc., the afterburner make script will download it
- check out and inspect the sample config.out files in afterburner/configs, e.g.,
- choose sample-config.out if you'd like to have para-virtualized linux guests
- choose sample-config-hvm.out if you'd like fully-virtualized guests (WARNING: WORK IN PROGRESS). Works only with Intel VMX
- create a build directory, run "make -f path/to/afterburner/Makefile", copy your favorite sample config into "build/config.out", run "make menuconfig" to edit the settings, finally run "make world", which will produce binaries in "build/boot"
- make "run-qemu" runs the afterburner in qemu

Just a quick tip: use gcc and g++ Versions 3, e.g. by running make CC=gcc3 CXX=g++3, or by putting "CC=gcc3" and "CXX=g++3" into the local build Makefile.

-Jan

--
Jan Stoess
System Architecture Group
University of Karlsruhe
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

--
Jan Stoess
KIT/UKa System Architecture Group
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

> -----Original Message-----
> From: l4ka-bounces@... [mailto:l4ka-bounces@...-
> karlsruhe.de] On Behalf Of Roberto Jung Drebes
> Sent: Friday, October 23, 2009 7:18 AM
> To: l4ka@...
> Subject: Device Driver Reuse
>
>
> Hello there,
>
> Is there anyone still working on the afterburner project? I'm trying
> to make some experiments with the device driver reuse framework, but
> have some questions about it. I contacted Josh LeVasseur but he told
> me he's not working on it anymore, unfortunately.
>
> I already downloaded the afterburner sourcecode through mercurial but
> am lost about how to setup the supporting environment. Tried to build
> the documentation but the figures are missing.
>
> Any tips?
>
> Thanks in advance,
>
> --
> Roberto Jung Drebes - Tokyo, Japan
> <drebes@...>
> http://japao.drebes.org/
>
>
>
>
>
>
>

From forum: l4ka@ira.uni-karlsruhe.de

RE: Conflict with multiboot module 0

2009-10-23T02:46:33Z

Hi Adam,

> my own little test user tasks to run as well. However, when I try to
> run a slightly larger program as the roottask, I never even get to
> launch the kernel. It dies with the message "Conflict with multiboot
> module 0\nPlease choose a different link base." The full output is:

You have to link roottask to a different base; the configure script should actually be able to do this for you:

~/build/pistachio-hg/user]~/devel/pistachio-hg/user/configure --help 2>&1 | grep linkbase
--with-kickstart-linkbase=BASE
--with-s0-linkbase=BASE link-base for sigma0 [[architecture-dependent]]
--with-roottask-linkbase=BASE

Best regards,
-Jan

--
Jan Stoess
KIT/UKa System Architecture Group
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

From forum: l4ka@ira.uni-karlsruhe.de

Device Driver Reuse

2009-10-22T22:18:05Z

Hello there,

Is there anyone still working on the afterburner project? I'm trying
to make some experiments with the device driver reuse framework, but
have some questions about it. I contacted Josh LeVasseur but he told
me he's not working on it anymore, unfortunately.

I already downloaded the afterburner sourcecode through mercurial but
am lost about how to setup the supporting environment. Tried to build
the documentation but the figures are missing.

Any tips?

Thanks in advance,

--
Roberto Jung Drebes - Tokyo, Japan
<drebes@...>
http://japao.drebes.org/

From forum: l4ka@ira.uni-karlsruhe.de

Conflict with multiboot module 0

2009-10-20T09:13:09Z

I have successfully compiled L4, so that the examples work, and have got
my own little test user tasks to run as well. However, when I try to
run a slightly larger program as the roottask, I never even get to
launch the kernel. It dies with the message "Conflict with multiboot
module 0\nPlease choose a different link base." The full output is:

grub> kernel /kickstart
, <0x800000:0x6600:0x149c>, shtab=0x808280
grub> module /x86-kernel
[Multiboot-module @ 0x816000, 0x2b8c1 bytes]

grub> module /sigma0
[Multiboot-module @ 0x842000, 0x16c66 bytes]

grub> module /rt
[Multiboot-module @ 0x859000, 0x3957e bytes]

grub> boot
Starting up ...

KickStart 0.13.06
Detected multiboot compliant loader
kernel (0x00816000-0x008418c1) => 0x00144040
(0x00816000-0x00824e96) -> 0x00100000-0x0010ee96
(0x00825000-0x0082ab00) -> 0x00110000-0x00115b00
(0x0082b000-0x00835a70) -> 0x00116000-0x00120a70
(0x00836000-0x008399e4) -> 0x00141000-0x001449e4
sigma0 (0x00842000-0x00858c66) => 0x00200000
_ (0x00843000-0x0084b410) -> 0x00020000-0x00028410
roottask (0x00859000-0x008196c) => 0x008000000
(0x0085a000-0x0088196c) -> 0x00800000-0x0082796c
Conflict with multiboot module 0 (0x00816000-0x008418c1)
Please choose a different link base
PANIC: FAIL in line 163

I have tried to work out how to solve this from the L4 source code, but
not succeeded. Could anyone please explain to me more exactly what the
problem is, and give some guidance to fixing it.

Many thanks,

Adam Antonik.

From forum: l4ka@ira.uni-karlsruhe.de

Re: booting question

2009-09-06T18:13:26Z

Finally I get this work, it is the problem that floppy image (fdimage.img) did not contain valid file system. I follow the section 2 to create floppy image that doesn't require root prvilage. Is there any chance to update the getting started page (http://l4ka.org/projects/pistachio/ia32/gettingstarted.php)? I think that would help newbie like me.

Thanks for help.

neo anderson wrote:

I follow the guide at http://l4ka.org/projects/pistachio/ia32/gettingstarted.php. but whilst executing to the step to startup from qemu (qemu -fda fdimage.img), the screen is always stops at grub menu.

grub> _

The config (config.out) is as below. Anything I did wrong? Thanks in advice. (In addition, the command I run almost the same as what stated in the guide, so there is no error shown while following those steps.)

#
# Automatically generated, don't edit
#
# Generated on: zion
# At: Fri, 07 Aug 2009 12:57:52 +0000
# Linux version 2.6.30-1-686-bigmem (Debian 2.6.30-5) (maks@debian.org) (gcc version 4.3.3 (Debian 4.3.3-15) ) #1 SMP Mon Aug 3 17:32:39 UTC 2009

#
# Pistachio Kernel Configuration System
#

#
# Hardware
#

#
# Basic Architecture
#
CONFIG_ARCH_X86=y
CONFIG_ARCH_POWERPC=n
CONFIG_ARCH_POWERPC64=n

#
# X86 Processor Architecture
#
CONFIG_SUBARCH_X32=y
CONFIG_SUBARCH_X64=n

#
# Processor Type
#
CONFIG_CPU_X86_I486=n
CONFIG_CPU_X86_I586=y
CONFIG_CPU_X86_I686=n
CONFIG_CPU_X86_P4=n
CONFIG_CPU_X86_K8=n
CONFIG_CPU_X86_C3=n
CONFIG_CPU_X86_SIMICS=n

#
# Platform
#
CONFIG_PLAT_PC99=y

CONFIG_SMP=n

#
# Miscellaneous
#
CONFIG_IOAPIC=n

#
# Kernel
#
CONFIG_IPC_FASTPATH=n
CONFIG_DEBUG=y
CONFIG_DEBUG_SYMBOLS=n
CONFIG_EXPERIMENTAL=n
CONFIG_PERFMON=n
CONFIG_SPIN_WHEELS=n
CONFIG_NEW_MDB=n
CONFIG_X86_SMALL_SPACES=n

#
# Debugger
#
CONFIG_KDB=y

#
# Kernel Debugger Console
#
CONFIG_KDB_CONS_KBD=y
CONFIG_KDB_CONS_COM=n

CONFIG_KDB_DISAS=n
CONFIG_KDB_ON_STARTUP=n
CONFIG_KDB_BREAKIN=n
CONFIG_KDB_BREAKIN_BREAK=n
CONFIG_KDB_BREAKIN_ESCAPE=n
CONFIG_KDB_INPUT_HLT=n
CONFIG_KDB_NO_ASSERTS=n

#
# Trace Settings
#
CONFIG_VERBOSE_INIT=n
CONFIG_TRACEPOINTS=n
CONFIG_KMEM_TRACE=n
CONFIG_TRACEBUFFER=n

#
# Code Generator Options
#

#
# Derived symbols
#
CONFIG_HAVE_MEMORY_CONTROL=n
CONFIG_X86_PSE=y
CONFIG_BIGENDIAN=n
CONFIG_X86_SYSENTER=n
CONFIG_X86_PGE=n
CONFIG_X86_FXSR=n
CONFIG_IS_32BIT=y
CONFIG_X86_HTT=n
CONFIG_X86_PAT=n
CONFIG_IS_64BIT=n
CONFIG_MULTI_ARCHITECTURE=n
CONFIG_X86_EM64T=n
CONFIG_X86_SMALL_SPACES_GLOBAL=n
CONFIG_X86_TSC=y
#
# That's all, folks!

From forum: L4Ka

RE: Sample applications freeze during execution

2009-08-20T04:21:50Z

Hi Andrew,

> I then attempted to modify one of the sample applications (grabmem),
> and I discovered that I could write directly to the screen buffer (0xb8000),
> which shows the application does load (but it is strange since as far as I
> know, printf also writes directly to the screen buffer, but printf does not
> appear to be doing anything).

If I'm not mistaken, both the kernel and the user implementation of printf
write to the serial port and not to the screen buffer by default.
For the kernel, you can change that behavior in the Debugger section of the
configuration menu by changing 'Kernel Debugger console' from 'Serial Port'
to 'Keyboard'.

> Also at the same time I discovered the system
> hangs during any attempt to communicate with sigma0 (through the functions
> provided in l4/sigma0.h).

Once you have proper debugger output, you could enable some tracepoints to
find out what's going on here. A hanging system at that early stage might
for example be caused by incorrectly handled pagefaults.

> I also noticed, in the kernel's build directory there is an include
> directory. However I don't see these files being referenced anywhere by the
> user code.

Not sure if I understand your problem here. The generated header files are just
used for building the kernel, not for building userlevel stuff.

> Also, I could write directly to 0xb8000 from the roottask. From my
> understanding, only sigma0 was suppose to have all physical memory allocated
> to it at boot, therefore for my roottask (or any other thread) to access the
> physical memory at this location I would need it mapped into the thread's
> local address space. So could some one please explain the memory protection
> and clear this up? Also, I'm unsure of at what location in virtual memory the
> kernel has been mapped.

When a pagefault occurs in the roottask, a pagefault IPC is sent to Sigma0.
If the pagefault occurred on a page of conventional memory (*), Sigma0 will
simply hand out the appropriate page (so the kernel will map it into the faulting
thread's address space), but only once. Thus, the roottask or some kind of memory
manager could/should simply grab all required memory at startup and then implement
more sophisticated pagefault handling policies.

(*) Note that the framebuffer is not part of the conventional memory pool, but
it seems that Sigma0 hands it out anyway when it's just touched.

HTH,
Philipp

From forum: l4ka@ira.uni-karlsruhe.de

Re:Sample applications freeze during execution

2009-08-18T16:06:40Z

Hi, Andrew. I'm newbie too, but I don't think you get the introduction
'Getting Started with L4Ka::Pistachio on ia32' by Ihor Kuz.

I followed the introduction and got the result. You'd better try qemu
first and then VMWare when you know L4Ka::Pistachio clearly.

Good luck.

From forum: l4ka@ira.uni-karlsruhe.de

Sample applications freeze during execution

2009-08-18T04:14:59Z

Hi,

I'm currently evaluating using the L4ka:Pistachio kernel on the x86 architecture as the core of an operating system project I am part of.

I'm building from the latest sources on the Mercury repository system with GCC 4.4.1 and Binutils 2.19.1.20090418 on Arch Linux (Linux 2.6.x). The build process completes flawlessly. I am trying to boot into the kernel through GRUB (I'm testing on VMware Workstation 6.5.2), by loading kickstart at the kernel, followed by the modules x86-kernel, sigma0, then one of the sample applications (pingpong, grabmem. l4test). Kickstart boots into the system, but once the kernel has loaded the system appears nonoperational:

[pasted below]

KickStart 0.13.06

Detected multiboot compliant loader

_kernel (0x00816000-0x00840995) => 0x001444a0

(0x00816000-0x00829192) -> 0x00100000-0x00113192

(0x0082a000-0x0082a4b8) -> 0x00115000-0x001154b8

(0x0082b000-0x0083500e) -> 0x00116000-0x0012000e

(0x00836000-0x00839fe8) -> 0x00141000-0x00144fe8

sigma0 (0x00841000-0x00857a8d) => 0x00020000

(0x00842000-0x0084a410) -> 0x00020000-0x00028410

roottask (0x00858000-0x0085ee02) => 0x00300000

(0x008f9000-0x0085d040) -> 0x00300000-0x00304040

Launching kernel ...

[/paste end]

But nothing more.

When I built the kernel will spin wheels enabled, I noticed it was animating as if the kernel was still functioning. I also attempted building with other kernel configurations enabled and disabled - all resulting in the same outcome. I then attempted to modify one of the sample applications (grabmem), and I discovered that I could write directly to the screen buffer (0xb8000), which shows the application does load (but it is strange since as far as I know, printf also writes directly to the screen buffer, but printf does not appear to be doing anything). Also at the same time I discovered the system hangs during any attempt to communicate with sigma0 (through the functions provided in l4/sigma0.h).

I also noticed, in the kernel's build directory there is an include directory. However I don't see these files being referenced anywhere by the user code.

( The prebuild 0.4 image functions correctly under VMWare. )

I don't understand what I am doing wrong, and if I may have missed any steps to get the system functioning?

Also, I could write directly to 0xb8000 from the roottask. From my understanding, only sigma0 was suppose to have all physical memory allocated to it at boot, therefore for my roottask (or any other thread) to access the physical memory at this location I would need it mapped into the thread's local address space. So could some one please explain the memory protection and clear this up? Also, I'm unsure of at what location in virtual memory the kernel has been mapped.

Thanks for all your help,

Andrew

From forum: l4ka@ira.uni-karlsruhe.de

booting question

2009-08-09T15:07:58Z

Sorry it seems like the previous mail was sent to the wrong place (l4ka@...). I apologize for the redundant message.

I follow the guide at http://l4ka.org/projects/pistachio/ia32/gettingstarted.php. but whilst executing to the step to startup from qemu (qemu -fda fdimage.img), the screen is always stops at grub menu.

grub> _

The config (config.out) is as below. Anything I did wrong? Thanks in advice. (In addition, the command I run almost the same as what stated in the guide, so there is no error shown while following those steps.)

#
# Automatically generated, don't edit
#
# Generated on: zion
# At: Fri, 07 Aug 2009 12:57:52 +0000
# Linux version 2.6.30-1-686-bigmem (Debian 2.6.30-5) (maks@...) (gcc version 4.3.3 (Debian 4.3.3-15) ) #1 SMP Mon Aug 3 17:32:39 UTC 2009

#
# Pistachio Kernel Configuration System
#

#
# Hardware
#

#
# Basic Architecture
#
CONFIG_ARCH_X86=y
CONFIG_ARCH_POWERPC=n
CONFIG_ARCH_POWERPC64=n

#
# X86 Processor Architecture
#
CONFIG_SUBARCH_X32=y
CONFIG_SUBARCH_X64=n

#
# Processor Type
#
CONFIG_CPU_X86_I486=n
CONFIG_CPU_X86_I586=y
CONFIG_CPU_X86_I686=n
CONFIG_CPU_X86_P4=n
CONFIG_CPU_X86_K8=n
CONFIG_CPU_X86_C3=n
CONFIG_CPU_X86_SIMICS=n

#
# Platform
#
CONFIG_PLAT_PC99=y

CONFIG_SMP=n

#
# Miscellaneous
#
CONFIG_IOAPIC=n

#
# Kernel
#
CONFIG_IPC_FASTPATH=n
CONFIG_DEBUG=y
CONFIG_DEBUG_SYMBOLS=n
CONFIG_EXPERIMENTAL=n
CONFIG_PERFMON=n
CONFIG_SPIN_WHEELS=n
CONFIG_NEW_MDB=n
CONFIG_X86_SMALL_SPACES=n

#
# Debugger
#
CONFIG_KDB=y

#
# Kernel Debugger Console
#
CONFIG_KDB_CONS_KBD=y
CONFIG_KDB_CONS_COM=n

CONFIG_KDB_DISAS=n
CONFIG_KDB_ON_STARTUP=n
CONFIG_KDB_BREAKIN=n
CONFIG_KDB_BREAKIN_BREAK=n
CONFIG_KDB_BREAKIN_ESCAPE=n
CONFIG_KDB_INPUT_HLT=n
CONFIG_KDB_NO_ASSERTS=n

#
# Trace Settings
#
CONFIG_VERBOSE_INIT=n
CONFIG_TRACEPOINTS=n
CONFIG_KMEM_TRACE=n
CONFIG_TRACEBUFFER=n

#
# Code Generator Options
#

#
# Derived symbols
#
CONFIG_HAVE_MEMORY_CONTROL=n
CONFIG_X86_PSE=y
CONFIG_BIGENDIAN=n
CONFIG_X86_SYSENTER=n
CONFIG_X86_PGE=n
CONFIG_X86_FXSR=n
CONFIG_IS_32BIT=y
CONFIG_X86_HTT=n
CONFIG_X86_PAT=n
CONFIG_IS_64BIT=n
CONFIG_MULTI_ARCHITECTURE=n
CONFIG_X86_EM64T=n
CONFIG_X86_SMALL_SPACES_GLOBAL=n
CONFIG_X86_TSC=y
#
# That's all, folks!

From forum: l4ka@ira.uni-karlsruhe.de

booting question

2009-08-09T15:04:37Z

I follow the guide at http://l4ka.org/projects/pistachio/ia32/gettingstarted.php. but whilst executing to the step to startup from qemu (qemu -fda fdimage.img), the screen is always stops at grub menu.

grub> _

The config (config.out) is as below. Anything I did wrong? Thanks in advice. (In addition, the command I run almost the same as what stated in the guide, so there is no error shown while following those steps.)

#
# Automatically generated, don't edit
#
# Generated on: zion
# At: Fri, 07 Aug 2009 12:57:52 +0000
# Linux version 2.6.30-1-686-bigmem (Debian 2.6.30-5) (maks@...) (gcc version 4.3.3 (Debian 4.3.3-15) ) #1 SMP Mon Aug 3 17:32:39 UTC 2009

#
# Pistachio Kernel Configuration System
#

#
# Hardware
#

#
# Basic Architecture
#
CONFIG_ARCH_X86=y
CONFIG_ARCH_POWERPC=n
CONFIG_ARCH_POWERPC64=n

#
# X86 Processor Architecture
#
CONFIG_SUBARCH_X32=y
CONFIG_SUBARCH_X64=n

#
# Processor Type
#
CONFIG_CPU_X86_I486=n
CONFIG_CPU_X86_I586=y
CONFIG_CPU_X86_I686=n
CONFIG_CPU_X86_P4=n
CONFIG_CPU_X86_K8=n
CONFIG_CPU_X86_C3=n
CONFIG_CPU_X86_SIMICS=n

#
# Platform
#
CONFIG_PLAT_PC99=y

CONFIG_SMP=n

#
# Miscellaneous
#
CONFIG_IOAPIC=n

#
# Kernel
#
CONFIG_IPC_FASTPATH=n
CONFIG_DEBUG=y
CONFIG_DEBUG_SYMBOLS=n
CONFIG_EXPERIMENTAL=n
CONFIG_PERFMON=n
CONFIG_SPIN_WHEELS=n
CONFIG_NEW_MDB=n
CONFIG_X86_SMALL_SPACES=n

#
# Debugger
#
CONFIG_KDB=y

#
# Kernel Debugger Console
#
CONFIG_KDB_CONS_KBD=y
CONFIG_KDB_CONS_COM=n

CONFIG_KDB_DISAS=n
CONFIG_KDB_ON_STARTUP=n
CONFIG_KDB_BREAKIN=n
CONFIG_KDB_BREAKIN_BREAK=n
CONFIG_KDB_BREAKIN_ESCAPE=n
CONFIG_KDB_INPUT_HLT=n
CONFIG_KDB_NO_ASSERTS=n

#
# Trace Settings
#
CONFIG_VERBOSE_INIT=n
CONFIG_TRACEPOINTS=n
CONFIG_KMEM_TRACE=n
CONFIG_TRACEBUFFER=n

#
# Code Generator Options
#

#
# Derived symbols
#
CONFIG_HAVE_MEMORY_CONTROL=n
CONFIG_X86_PSE=y
CONFIG_BIGENDIAN=n
CONFIG_X86_SYSENTER=n
CONFIG_X86_PGE=n
CONFIG_X86_FXSR=n
CONFIG_IS_32BIT=y
CONFIG_X86_HTT=n
CONFIG_X86_PAT=n
CONFIG_IS_64BIT=n
CONFIG_MULTI_ARCHITECTURE=n
CONFIG_X86_EM64T=n
CONFIG_X86_SMALL_SPACES_GLOBAL=n
CONFIG_X86_TSC=y
#
# That's all, folks!

From forum: L4Ka

RE: Error by building the user-level code

2009-06-24T02:59:01Z

Hi Raoul,

config.h.in should have been created by autoheader (in the user source directory). Could you verify that your autoheader version generates that file? If not, can you try a different version (e.g., 2.13 or 2.50) and see if that works?

-Jan

--
Jan Stoess
System Architecture Group
University of Karlsruhe
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

From forum: l4ka@ira.uni-karlsruhe.de

[ANNOUNCE] Introducing Codezero

2009-06-11T04:29:39Z

Hi Everyone,

I would like to announce my ongoing work on a new L4 microkernel called
Codezero. Codezero is a modern L4 microkernel implementation written in
C. It targets embedded platforms, supports the ARM architecture, and
aims to implement both virtualization and native OS components in one
system.

Codezero has a design and API that is similar to other L4 microkernels
such as Pistachio.

The software currently comes with two services: First one is the default
pager called MM0 that provides memory management capabilities with a
POSIX-like API. It supports proper demand paging and implements calls
such as fork, clone, execve, exit, mmap, shm.

The second service is called FS0 and it implements the virtual
filesystem layer. This service supports calls such as open, close, read,
write, lseek, stat, fsync, etc.

The software comes with a GPLv3 license, and a copyright share agreement
option for contributions. The source code base is fairly clean and easy
to play with. I encourage anybody interested in development to join.

For more details:

http://www.l4dev.org

Thanks,

--
Bahadir Balban

From forum: l4ka@ira.uni-karlsruhe.de

Error by building the user-level code

2009-06-10T01:19:29Z

Hallo,

I want to get running the l4ka::pistachio on my Debian system. By reading the online document "Getting Started with l4ka::pistachio on ia32", I have follow the instruction but when a try to build the user-level code (when i type the make command) i get the following error:

make[1]: Entering directory `/home/raoul/L4ka/l4ka-pistachio-b675e9a25001/ia32-user-build/lib'
make[2]: Entering directory `/home/raoul/L4ka/l4ka-pistachio-b675e9a25001/ia32-user-build/lib/l4'
make[2]: Für das Ziel »all« ist nichts zu tun.
make[2]: Leaving directory `/home/raoul/L4ka/l4ka-pistachio-b675e9a25001/ia32-user-build/lib/l4'
make[2]: Entering directory `/home/raoul/L4ka/l4ka-pistachio-b675e9a25001/ia32-user-build/lib/io'
make[2]: *** Keine Regel vorhanden, um das Target »config.h«,
benötigt von »ia32-getc.o«, zu erstellen. Schluss.
make[2]: Leaving directory `/home/raoul/L4ka/l4ka-pistachio-b675e9a25001/ia32-user-build/lib/io'
make[1]: *** [subdirs-all] Fehler 2
make[1]: Leaving directory `/home/raoul/L4ka/l4ka-pistachio-b675e9a25001/ia32-user-build/lib'
make: *** [subdirs-all] Fehler 2

Please, could anyone tell me what I am doing bad
I have enter the following command when trying the step2: build user-level to run:

raoul@pluto:~/L4ka/l4ka-pistachio-b675e9a25001/user$autoconf -> to get the configure file

raoul@pluto:~/L4ka/l4ka-pistachio-b675e9a25001/user$autoheader -> to get the config.h.in file

raoul@pluto:~/L4ka/l4ka-pistachio-b675e9a25001/ia32-user-build$ ../user/configure --prefix=$(pwd)/../ia32-user-install --with-kerneldir=../x86-kernel-build/

raoul@pluto:~/L4ka/l4ka-pistachio-b675e9a25001/ia32-user-build$ make -> At this stage I get the above given error message

Thank you for your response.

Raoul

From forum: l4ka@ira.uni-karlsruhe.de

RE: Build error for Amd64

2009-06-09T03:59:06Z

Hi Ambrosehuang Ambrose,
Excuse the late response. The function was missing; I've just added it to the HG repo. Thanks for pointing it out.

-Jan

--
Jan Stoess
System Architecture Group
University of Karlsruhe
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

From forum: l4ka@ira.uni-karlsruhe.de

Build error for Amd64

2009-05-29T20:30:24Z

Hi, I'm a newbie for L4ka:pistachio, I build the __LASTEST__ pistachio
kernel on my amd64 5000+ debain lenny box, with following basic
configuration:
---------------------------------------------------------------------------------------------------------------------------
ARCH=x86
SUBARCH=x64
CPU=k8
PLATFORM=pc99
...
-----------------------------------------------------------------------------------------------------------------------------

but when I enable CONFIG_SMP_IDLE_POLL
----------------------------------------------------------------------------------------------------------------------------
#define CONFIG_SMP 1
#define CONFIG_SMP_MAX_PROCS 4
#define CONFIG_SMP_IDLE_POLL // enable IDLE_POLL
----------------------------------------------------------------------------------------------------------------------------

build failed with errors:

/home/ambrosehua/project/l4_kernel/l4ka/l4ka-pistachio/kernel/src/api/v4/schedul
e.cc:531:
undefined reference to `processor_sleep()'
kdb/platform/pc99/io.o: In function `getc_serial':
/home/ambrosehua/project/l4_kernel/l4ka/l4ka-pistachio/kernel/kdb/platform/pc99/
io.cc:344:
undefined reference to `processor_sleep()'
make[1]: *** [x86-kernel] Error 1
make[1]: Leaving directory `/home/ambrosehua/project/l4_kernel/l4ka/build-amd64'
make: *** [all] Error 2

otherwise, with CONFIG_SMP_IDLE_POLL disabled, build succeeded.

I search the code repo, and found no implementation for function
processor_sleep in schedule.h.
and I also search the mail archive found no related info. Is this
feature unavailable or did I miss something ?

From forum: l4ka@ira.uni-karlsruhe.de

RE: issue in afterburner--same as " Afterburner running problem" thread

2009-04-24T01:29:24Z

> now when i do "make run-qemu" as mentioned in readme.txt, the boot
> process
> starts but when it tries to load the ramdisk, it gets struck there and
> nothing
> comes up after that.

Ok since there are many possible failure scenarios, I don't have a standard answer. In general, however, you want to find out what the guest and monitor are doing. A couple of options to do this:

- Use L4 Tracepoints, a source code based tracing facility to log predefined kernel and user events such as IPC, page faults, etc. Tracepoints are configured and used via KDB ("r"); they must be enabled in the pistachio kernel menu. You can instruct KDB to print the event to the console and/or to enter KDB upon the event.
- Use L4 Tracebuffer, a memory buffer that logs all the kernel and user tracepoints into an in-memory log buffer. Tracepoints are also configured and used via KDB ("y"); they must also be enabled in the pistachio kernel menu.
- Find out, via KDB and the binary executables, where guest and monitor are running and what data is contained on their stack. You can do so by again using KDB to inspect TCBs, stack pointer, instruction pointer and the memory they are referencing.

Best,
-Jan

--
Jan Stoess
System Architecture Group
University of Karlsruhe
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

From forum: L4Ka

issue in afterburner--same as " Afterburner running problem" thread

2009-04-22T11:15:28Z

Hi

One more problem here :)

I tried using afterburner also. did the stuff mentioned in readme.txt.

I was able to create a bootable iimage as mentioned.

now when i do "make run-qemu" as mentioned in readme.txt, the boot process
starts but when it tries to load the ramdisk, it gets struck there and nothing
comes up after that.

It is same as the issue mentioned in previous thread named " Afterburner running
problem:".

I entered in kdb and looked into the stuff. things look good there.i saw some
irq's, roottask and some other stuff there in schedule q.

can you please suggest what more needs to be chacked and what can be wrong here.

thanks

From forum: L4Ka

Check out my photos on Facebook

2009-04-16T19:26:21Z

Facebook

facebook

Muhammad Saufy Rohmad has:
89 friends
1 photo
1 note
42 wall posts
2 groups

Check out my photos on Facebook

Hi L4ka,

I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile.

Thanks,
Muhammad

To sign up for Facebook, follow the link below:

http://www.facebook.com/p.php?i=546038458&k=3XCU54UZSXVM51AAVEW5TP&r

l4ka@... was invited to join Facebook by Muhammad Saufy Rohmad. If you do not wish to receive this type of email from Facebook in the future, please click here to unsubscribe.
Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301.

From forum: L4Ka

Re: [PATCH] fix improper return of local sender TID in propagated IPC

2009-04-09T08:36:36Z

On Wed, Apr 08, 2009 at 02:24:24PM +0200, Jan Stoess wrote:

> Thanks for the patch. It makes sense to me, and I have committed it to the
> repository. Apparently the local ID logic doesn't handle the propagation
> case very well.
>

No doubt there could be a more elegant solution as well, but that one seems
to do the locally right thing, for what it's worth.

> > As requiring that the VirtualSender TCR always contain a global TID when
> > propagation is specified in the message tag, I'd like to recommend that
> > the L4.X2 spec be revised accordingly.
>
> Hmm. I actually wouldn't want change the spec. The implementation follows
> the spec, not vice versa. And just because the implementation doesn't
> handle every (corner) case or contains bugs, I don't see any conceptual
> reason why local IDs shouldn't be used when propagating messages.
>

That sounds reasonable too, i.e. the kernel can convert a local ID in
VirtualSender to the appropriate ID for returning to the IPC recipient where
necessary -- entirely regardless of which format the ID given by the IPC
sender was in.

It's good to know this was just an implementation artifact.

> > [2] IMO, silently disabling propagation is the wrong thing to do as it
> > tells the sender that the IPC operation succeeded as specified when it
> > did not. This behaviour also diverges from that of Pistachio 0.4 .
>
> That's debatable. The spec says: "If originator thread and current sender,
> or current sender and receiver reside in the same address space,
> propagation is always permitted. Otherwise, IPC occurs unpropagated.". The
> implementation actually implements that behavior, and it seems to be an
> unwanted side-effect that local IDs don't work there and that the
> implementation then continues with the IPC, but unpropagated.

I should've said "... that the IPC operation succeeded as expected by the
caller when it did not", i.e. my critique was toward the spec rather than
the implementation.

It would be interesting to learn the rationale for this behaviour. From a
naive reading of the way IPC is specified in L4.X2, propagation feels like a
hack (i.e. the designers having added a new behaviour to the IPC syscall and
a new TCR, but keeping the existing set of error conditions so as to re-use
existing code without modification) -- but that sounds implausible given how
it fits with clans-and-chiefs, which (IIRC) has been around for quite a
while.

> An ASSERT catching local IDs might be more appropriate in this case.
>

Agreed. Even if non-propagation with "p" set were reported as an error
status, there don't seem to be any obvious things that the sender could do
to recover besides logging the unexpected condition and general attempts to
return to a known-good state.

On the other hand, delivering a "not quite propagated" message to the
recipient may cause all sorts of confusion in operations where the sender's
ID is significant. On the third hand, a case can be made that regardless of
whether delivery occurs, the system as a whole is already behaving in an
undefined manner and that lossage of some kind is bound to occur. (Side
effects of such a misdelivery would presumably be limited to things that are
identified by the ID of the propagator, and so wouldn't be devastating by
themselves.)

--
Kalle A. Sandstro"m ksandstr@...
746B 4B14: BFB5 6D3B 0758 CFBE 11F9 DF41 4C28 67FB 746B 4B14
void *truth = &truth; http://ksandstr.iki.fi/

From forum: L4Ka

RE: [PATCH] fix improper return of local sender TID in propagated IPC

2009-04-08T05:24:24Z

Hello Kalle,

Thanks for the patch. It makes sense to me, and I have committed it to the repository. Apparently the local ID logic doesn't handle the propagation case very well.

> As requiring that the VirtualSender TCR always contain a global TID
> when propagation is specified in the message tag, I'd like to recommend
> that the
> L4.X2 spec be revised accordingly.

Hmm. I actually wouldn't want change the spec. The implementation follows the spec, not vice versa. And just because the implementation doesn't handle every (corner) case or contains bugs, I don't see any conceptual reason why local IDs shouldn't be used when propagating messages.

> If it matters for a short patch like this, the attached changeset is
> licensed under the two-clause BSD license as given at the start of the
> source file it modifies.

Yes, that actually matters. BSD license is fine, though. Thanks.

> [2] IMO, silently disabling propagation is the wrong thing to do as it
> tells
> the sender that the IPC operation succeeded as specified when it
> did
> not. This behaviour also diverges from that of Pistachio 0.4 .

That's debatable. The spec says: "If originator thread and current sender, or
current sender and receiver reside in the same address space, propagation is always permitted.
Otherwise, IPC occurs unpropagated.". The implementation actually implements that behavior, and it seems to be an unwanted side-effect that local IDs don't work there and that the implementation then continues with the IPC, but unpropagated. An ASSERT catching local IDs might be more appropriate in this case.

Best,
-Jan

--
Jan Stoess
System Architecture Group
University of Karlsruhe
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

From forum: L4Ka

[PATCH] fix improper return of local sender TID in propagated IPC

2009-03-28T15:36:50Z

The attached patch[1] fixes a problem where a recipient may get the thread
ID of a propagating thread rather than the propagator's VirtualSender TCR.

This misbehaviour was observed when the propagator and the recipient were in
one address space and the original sender was in another, and the propagator
went through a blocking send phase to deliver the message. The issue was
that at the end of the last function in kernel/src/api/v4/ipc.cc,
from_tcb->get_global_id() was used interchangeably with
current->get_partner() when in the propagating case they almost certainly
refer to distinct threads.

As for why this was only observed in a blocking-send case and not in the
non-blocking case, I have no idea. I only drilled down from the return value
observed by the recipient, and correcting it seemed the right thing to do.

The changeset also enforces, using an ASSERT(), the notion that the virtual
sender in IPC propagation is always identified by global TID. This is
supported by lines 313-329 in kernel/src/api/v4/ipc.cc, which silently
disables[2] propagation if VirtualSender is not a global TID (as a local TID
cannot be equal to the result of get_global_id() of the virtual sender's
tcb_t).

As requiring that the VirtualSender TCR always contain a global TID when
propagation is specified in the message tag, I'd like to recommend that the
L4.X2 spec be revised accordingly.

If it matters for a short patch like this, the attached changeset is
licensed under the two-clause BSD license as given at the start of the
source file it modifies.

[1] hg bundle -- I hope this is the correct format

[2] IMO, silently disabling propagation is the wrong thing to do as it tells
the sender that the IPC operation succeeded as specified when it did
not. This behaviour also diverges from that of Pistachio 0.4 .

--
Kalle A. Sandstro"m ksandstr@...
746B 4B14: BFB5 6D3B 0758 CFBE 11F9 DF41 4C28 67FB 746B 4B14
void *truth = &truth; http://ksandstr.iki.fi/

pistachio-propagate-partner-properly.hg (1K) Download Attachment

From forum: L4Ka

How about a 0.5 release?

2009-03-25T08:19:05Z

The 0.4 release has become very old. Old enough to not compile with a modern
version of G++, old enough for the compiler it _can_ be compiled with to not
ship in the two most recent major releases of Debian GNU/Linux. That is
quite old indeed.

So my question is: are there plans to do a 0.5 release of L4Ka::Pistachio?

To provide a bit of context, over the past three or so years I've been
hobbyhorsing together an Unix-like operating system personality on top of
the Pistachio microkernel. (It's available under the GPLv3 at
http://muix.ath.cx for those interested.) For now, it has been written
against the 0.4 headers and quirks[1], but that revision has become
virtually unusable by itself due to reasons mentioned above, and others.

Thus I couldn't release a 0.1 of µiX even if I wanted to: it'd be
unbuildable against the (soon five years old) Pistachio 0.4 simply because
Pistachio can't be compiled as found in the 0.4 tarball on l4ka.org . The
unsatisfactory alternatives would involve taking a development version from
the Mercurial tree and tarballing it up for distribution as a "companion to
µiX 0.1", or developing a large and ultimately pointless patchset against
Pistachio 0.4 to make it compile with g++ 4.3 .

If there are significant issues featurewise with regard to releasing 0.5 as
a snapshot of the Mercurial tree[2], then are these issues large enough to
not release a 0.5 given the problems in retaining 0.4 as the most recent
formal release?

[1] such as the extra parentheses in a caching hint #define, and how the
header file that defines L4_BootRec_t isn't copied into the install
directory.

[2] I noted paths in the scheduling code marked as "hole", and a major
problem in kickstart failing to avoid stepping on boot modules when
relocating sigma0, the root task and so forth.

--
Kalle A. Sandstro"m ksandstr@...
746B 4B14: BFB5 6D3B 0758 CFBE 11F9 DF41 4C28 67FB 746B 4B14
void *truth = &truth; http://ksandstr.iki.fi/

From forum: L4Ka