l4-hackers June 2007

l4-hackers@os.inf.tu-dresden.de

25 participants
27 discussions

Playing with ORe
by Marc CHALAND 22 Jun '07

22 Jun '07

Hi everybody, I did some experiments with ORe. I played with arping and I modified it to reply to ICMP from windows. I also added one option to ORe to prevent promiscuous mode when not necessary. cf attachment Best Regards

2 1

Thesis on verification of Fiasco's IPC implementation
by Erik Schierboom 22 Jun '07

22 Jun '07

Hi all, As some of you will probably already know, I have been working on the verification of (a part of) Fiasco's IPC implementation. This week I have finished my thesis and the result can be found at the following location: http://www.swyp.nl/thesis.pdf Thanks for all the help I have received. With regards, Erik Schierboom

1 0

Re: 16-bit code and L4
by Valery V. Sedletski 22 Jun '07

22 Jun '07

>On Thu Jun 21, 2007 at 03:55:24 +1300, Valery V. Sedletski wrote: >> >>> 2) Must all the segment registers be CS == DS == ES == FS == GS == SS == FLAT in L4 usermode >> >programs (in Intel >> >>> architecture implementation)? Or, there exist a possibility to use segments other than FLAT? >> >>> >> >>Fiasco preserves some of these segments (e.g., GS to support thread >> >>local storage). However, unless OS/2 makes use of these segments in >> >>32-bit mode there is no need to change these from a flat setting. >> > >> >It seems, that OS/2 does not use GS (GS seems to be always == 0), at least, in application programs. >> > >> >> But also FS is used to address a structure named Thread Info Block >> (TIB), it is also not flat (it has a limit=0x30) So, FS is used by >> OS/2 and programs depend on it. GS seems to be not used, and ES and DS >> are generally flat. > >Fiasco makes some GDT slots available to userland so that FS and GS can >be used with those. > And how to access these GDT descriptors from userland? Is this documented somewhere? Can usermode task change attributes of these descriptors (such as "16-bits" attribute)? Are they (descriptors) somehow mapped to requestor's address space or how else can usermode task modify these descriptors? Or, can usermode task only load selectors corresponding to these descriptors, but not modify descriptors itself? So it is with Fiasco, and what about Pistachio? (Is this mailing list the right place to ask such questions, or it is better to ask them at l4ka(a)ira.uka.de?) And what about DS/ES? Can usermode task load these registers with another selector, as with FS/GS? > > >Adam >-- >Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ >

3 2

Re: 16-bit code and L4
by Valery V. Sedletski 20 Jun '07

20 Jun '07

>>> 2) Must all the segment registers be CS == DS == ES == FS == GS == SS == FLAT in L4 usermode >programs (in Intel >>> architecture implementation)? Or, there exist a possibility to use segments other than FLAT? >>> >>Fiasco preserves some of these segments (e.g., GS to support thread >>local storage). However, unless OS/2 makes use of these segments in >>32-bit mode there is no need to change these from a flat setting. > >It seems, that OS/2 does not use GS (GS seems to be always == 0), at least, in application programs. > But also FS is used to address a structure named Thread Info Block (TIB), it is also not flat (it has a limit=0x30) So, FS is used by OS/2 and programs depend on it. GS seems to be not used, and ES and DS are generally flat.

2 1

16-bit code and L4
by Valery V. Sedletski 20 Jun '07

20 Jun '07

Would be someone so kind to answer some questions? These questions are about 16-bit instructions execution on intel processors in L4 usermode programs. First, excuse me for my bad English (it is not native for me). And first I'll try to explain the motivation. -- I am now trying to contribute to the project aiming to create an Opensource OS/2 clone. (osFree aka OS/3 project, http://www.osfree.org/) The goal now is to create OS/2 API implementation with binary compatibility with existing OS/2 (intel) applications. Also, it would be desirable to reuse existing OS/2 device driver base (if it is possible). We are planning to use L4 as a base for API implementation. The problem with existing OS/2 applications is that they are not pure 32-bit; there are many common 16-bit API's now (they are to be replaced with 32-bit analogues in new implementation); almost each LX format executable contains 16-bit fragments (thunks for calling 16-bit API's), though the most of each executable is 32-bit and uses 32-bit flat memory model. Also, most old OS/2 device drivers are 16-bit, they are still very common now (but newer drivers are 32-bit). Another problem is that many drivers and applications are available in binary-only form (so, they cannot be recompiled, as with Linux) 32-bit applications and drivers support can be made, for example, by implementing a converter of LX-executables to pure 32-bits. Also, 16-bit fragments can be executed in a virtual machine. Or, as another variant, it may be possible to execute these 16-bit parts on a real processor. The problem is only how to maintain correct segment registers values and how to add a 16-bit segment descriptor to GDT or LDT. The problem with L4 is that it doesn't expose segmentation to outside the kernel, it abstracts segmentation from usermode programs and only allows to use paging, but not segmentation. The reason is known: segmentation is not portable, it has no analogues on other architectures than intel one. So, the questions are: 1) There is L4Linux. It is mostly 32-bit. But as I know, the Linux kernel also contains some 16-bit parts, such as setup code (it works with BIOS routines and probes hardware), and also (as I heard) acpi suspend/wakeup code. So, it contains 16-bit segments. But doesn't it interfere with L4? How did the people porting Linux to the L4 microkernel solve the problem of 16-bit code? And doesn't it interfere with ELF format capabilities (it is pure 32/64-bit, as I understand)? 2) Must all the segment registers be CS == DS == ES == FS == GS == SS == FLAT in L4 usermode programs (in Intel architecture implementation)? Or, there exist a possibility to use segments other than FLAT? 3) Is it possible to cause the L4 kernel to create 16-bit segment descriptor on Intel architecture?

2 2

Re: Fiasco@ARM - supported hardware
by Daniel Vandersee 19 Jun '07

19 Jun '07

Hi Jorge, I just tried it and it doesn't work for me, too. If I break the program execution after a while it always stops at uart_write+72: > 0xb0002e30 <uart_write+64>: ldr r3, [r2, #32] > 0xb0002e34 <uart_write+68>: tst r3, #4 ; 0x4 > 0xb0002e38 <uart_write+72>: beq 0xb0002e30 <uart_write+64> > 0xb0002e3c <uart_write+76>: ldrb r3, [r0, r12] Did you got it running with skyeye? Attached you will find my skyeye configuration. Maybe you have an idea what goes wrong here? Thanks! Cheers, Daniel Jorge Torres schrieb: > Hi Daniel, > > Have you tried PXA borad with skyeye? > > Thanks, > > JOrge > > On 6/18/07, *Daniel Vandersee* < dvandersee(a)escrypt.com > <mailto:dvandersee@escrypt.com>> wrote: > > Hello, > > how do you test L4 on an ARM platform? Do you have specific hardware > for > that purpose? You mentioned that you use ARM Integrator boards. As there > are several integrator boards available: which one exactly do you use? > Do you use other boards as well? I'm asking because I plan to buy an > ARM > board which is supported out of the box without the need to modify > drivers. > > Do you additionally use software simulators to test L4? If so, which one > do you use? I tried Skyeye to simulate an ARM integrator board as well > as a SA1100-board but didn't get any output over the serial line. Qemu > doesn't work either and terminates with the following error: "qemu: > uncaught target signal 11 (Segmentation fault) - exiting". > > Kind regards, > Daniel > > > > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de <mailto:l4-hackers@os.inf.tu-dresden.de> > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > > cpu: xscale #cpu: pxa25x mach: pxa_lubbock #cpu: pxa27x #mach: pxa_mainstone mem_bank: map=I, type=RW, addr=0x40000000, size=0x0c000000 mem_bank: map=M, type=RW, addr=0xb0000000, size=0x10000000 #mem_bank: map=M, type=RW, addr=0xd0000000, size=0x00100000 #log: logon=1, logfile=/tmp/sk2.log, start=500000, end=1500000 #lcd:state=on,type=pxa,mod=gtk uart: mod=stdio

1 0

Re: L4Env Building Problem!
by Bjoern Doebel 14 Jun '07

14 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marius.bao wrote: >> Please enter l4/pkg/bootstrap/server/src, run "make V=1" and post the >> complete output here. >> > When I run "make V=1", the make process stops. The output is as follows: > ../../../../mk/Makeconf:120: *** need to give builddir with > O=.../builddir. Stop. Sure, then please run make V=1 O=<path_to_your_builddir> and post the complete output here. > Ps:The ../../../../ directory is l4. > I couldn't compile a package separately. When I want to compile a > single package, I have to enter the build directory to run "make", and > compile all the packages. I suffered a lot as the compile process > takes a long time. You can build (parts of) a single package in at least 2 ways: 1. use the O=<builddir> option when running make just as the error message above tells you. 2. Go to the builddir. There will be a subdirectory pkg with build dirs for all the packages. You can enter these and only build a single one. Regards, Bjoern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcOTNP5ijxgQLUNkRAvWjAJ9ipIMpC2VA1et+nzf2JtJeqaWhLgCfRnb2 E0j6eVEgzO+AZVvOKDrSHL0= =c4iI -----END PGP SIGNATURE-----

1 0

Re: L4Env Building Problem!
by Marius.bao 13 Jun '07

13 Jun '07

Hi, >Could you find out which dice binary is used (run "make V=1" in one of >the idl directories, for instance tudos/l4/pkg/names/idl)? And then run >that binary with the --version option and post the output here? It turned out that i used an old version of DICE, I update to the latest version, and it works correctly. Thanks a lot :) when I compiled the bootstrap package, another problem occured: l4/pkg/bootstrap/server/src/startup.cc:215: undefined reference to `__cxa_guard_release' maybe my gcc is too old. my gcc version is gcc-3.4.2.6-fc3

2 1

L4Env Building Problem!
by Marius.bao 11 Jun '07

11 Jun '07

Hi, Thanks for previous information. I've checkouted l4env using: svn checkout -N http://svn.tudos.org/repos/tudos/trunk tudos cd l4 ./repomgr co l4env When I tried to compile l4env, errors occured in some idl file. eg: names.idl in names package import <l4/sys/types.h> import <l4/names/libnames.h> /** IDL interface of the name server. */ interface names { long register([in, string] char *name); long register_thread([in, string] char *name, [in] l4_threadid_t id); long unregister_thread([in, string] char *name, [in] l4_threadid_t id); long unregister_task([in] l4_threadid_t id); long query_name([in, string] char *name, [out] l4_threadid_t *id); long query_id([in] l4_threadid_t id, [out, string, prealloc_client, max_is(NAMES_MAX_NAME_LEN)] (*) char **name);modified ...... }; errors occured in the last function at the (*) line, the error information is as follows: unknown attribute dice: 1 Error(s) and 0 Warning(s) occured. when I modified the function into long query_id([in] l4_threadid_t id, [out, string] char **name); It compiles OK. I don't know what's the problem as I know little about the corba idl.

2 1

Re: l4-hackers Digest, Vol 50, Issue 7
by Erik Schierboom 09 Jun '07

09 Jun '07

> Message: 4 > Date: Fri, 8 Jun 2007 00:17:26 +0200 > From: Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> > Subject: Re: Verify Fiasco assertion using pingpong > To: l4-hackers(a)os.inf.tu-dresden.de > Message-ID: <20070607221726.GN14071(a)os.inf.tu-dresden.de> > Content-Type: text/plain; charset=iso-8859-1 > > > On Thu Jun 07, 2007 at 13:17:09 +0200, eschierb(a)sci.kun.nl wrote: > >> Quoting Martin Pohlack <mp26(a)os.inf.tu-dresden.de>: >> >> >>> eschierb(a)sci.kun.nl wrote: >>> >>> [...] >>> >>> >>>> "/bin/bash: did_not_find_dice___please_install_dice: command not found" >>>> >>> Did you build Dice? It got moved recently in the SVN from l4/tools/dice >>> to tools/dice. I think you have to build it manually. >>> >>> Cheers, >>> Martin >>> >>> >> I believe I did, by invoking the following commands: >> >> " >> cd dice >> ./bootstrap >> ./configure >> ./make >> " >> > > When being in the l4 directory, does calling > ../dice/src/dice > work or not? I.e. is there a dice binary? > > > > Adam > Calling ../dice/src/dice does work so there is a DICE binary, but when I call "make O=/tmp/build" in the l4 directory I still get the following error: if [ -r ../dice/Makefile.drops ]; then \ make -C ../dice -f Makefile.drops; \ fi make[1]: Entering directory `/tmp/tudos/dice' ../l4/mk/Makeconf:155: Sorry, your object or source path became garbled. ../l4/mk/Makeconf:156: OBJ_BASE: /tmp/build ../l4/mk/Makeconf:157: SRC_BASE_ABS: /tmp/tudos/l4 ../l4/mk/Makeconf:158: SRC_DIR: /tmp/tudos/dice ../l4/mk/Makeconf:159: OBJ_DIR: /tmp/tudos/dice ../l4/mk/Makeconf:160: PKGDIR: ../l4/mk/Makeconf:161: L4DIR_ABS: /tmp/tudos/l4 ../l4/mk/Makeconf:162: PKGDIR_ABS: ../l4/mk/Makeconf:163: PKGDIR_OBJ: /tmp/tudos/dice ../l4/mk/Makeconf:164: *** Please investigate.. Stop. make[1]: Leaving directory `/tmp/tudos/dice' make: *** [../dice] Error 2

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers June 2007