- l4-hackers - example.com Site

patching grub
by Emanuel Thomas 21 Jun '05

21 Jun '05

Hallo, I tried to patch the grub from the cvs but that doesn't work. It seems that there are files missing in the cvs, like: configure.ac docs/multiboot.info /stage2/terminfo.c I've tried the grub patch 0.95, 0.96 and 0.97 (from http://os.inf.tu-dresden.de/~adam/grub/) Emanuel Thomas

2 1

fprov-l4 problem
by fabs0028＠free.fr 21 Jun '05

21 Jun '05

Hello, well now my l4linux is fully working and i find it pretty fast (except when i left only 32mB of ram for l4linux of course). I would like to launch some l4 programs from l4linux so i need to run fprov-l4 first but when i do so, i got a message telling me that fprov is running and then my system crash (it freezes totally and i have no choice but reboot). it seems that fprov-l4 got stuck on a system call (it hangs on a int $0x80) Thanx for your help :) Fabien Chaillou

2 1

Re: L4 ethernet driver and stack setup
by Frank Mehnert 20 Jun '05

20 Jun '05

On Monday 20 June 2005 16:32, you wrote: > So if I want to use the loader to load an task which does for example > DMA, how do I ensure that the allocated buffers are mapped 1-2-1? I can > not use the attribute hack with dynamically allocated memory. Right. Better software than GRUB have some function like virt_to_phys() which is called for every data buffer. This function can be easily implemented using the phys_addr feature of the dm_phys dataspace manager (see dm_phys/doc for more documentation). Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##

1 0

L4 ethernet driver and stack setup
by Leon Brits 20 Jun '05

20 Jun '05

Hi all, I've "extracted" the E1000 driver code from the TFTP server to get some packet data directly into L4. I've noticed that if I load this task with the loader then the TX part sends garbage. I then added (for fun) the attribute (section "STACK") to the buffer from which the packet is send and now it works. Can anybody explain this to me! Send a link to some use full doc? Thanks Leon

2 1

Please help to start development on top of L4
by kathiravel thayapararajh 19 Jun '05

19 Jun '05

Hi, I am interested in developing small Real Time OS on top the L4. But, I am a beginer in L4. I've successfully installed L4Ka::Pistachio on P4 machine. Now i want to practice L4 programming. To do that, which platform i want to use. i mean, is it possible to work on Redhat Linux and test it in the L4Ka::Pistachio or i want to go for any other enviornment on L4. Since I am a beginer, Could anybody please help me by giving some idea. then i able to start working on L4. Thanks in advance. Regards, Thayapararajh. ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com

3 2

Announcing Magpie, an L4 interface generator
by Nicholas FitzRoy-Dale 19 Jun '05

19 Jun '05

Hi everyone, I'm pleased to announce the first public release of the Magpie interface generator. Magpie was written at the University of NSW over the course of the last six months to support several operating system projects. It was inspired by, and owes a large debt to, the de facto interface generator for L4, IDL4. Magpie's advantages over IDL4, are in its use of templates for output, allowing rapid changes to output modes and easy sharing of output code, and its support for the ARM architecture. On the flip side, Magpie does not currently support DCE IDL, long IPC, or optimised stub support for the ia32 architecture. New output modes, such as component orientation and C++ support, are in development and planned for a future release. Magpie is currently experimental software, under active development. If you use it, I would be very interested to hear any reports, both positive and negative. Bug reports are, of course, particularly appreciated. Magpie can be downloaded from here: http://www.disy.cse.unsw.edu.au/Software/Magpie/ Nicholas FitzRoy-Dale DiSy group, UNSW

1 0

Rights Amplification
by Marcus Brinkmann 16 Jun '05

16 Jun '05

Hi, Last week when Neal was visiting Dresden, he explained how rights amplification (i.e. passing capabilities as arguments to capability object invocation) doesn't work with the current L4 capability framework. The specific example he gave was that of a memory server which provides so-called memory containers and the ability to copy memory between memory containers using something like: container_copy (A, a_start, B, b_start, length) where A and B are capabilities/end points presumably to the memory containers. To perform a container_copy, the client would send an IPC to the capability/end point A and map B to the server. The server is told the id of the receive end of the end point A and thus can easily find the server object associated with A, however, it has no way to derive the receive id of B (even though it serves B) and thus has no way to find the associated server object. The following discussion presents the problem more generally, shows that the above is a special case of a larger problem and presents a solution which minimally modifies the current L4 capability proposal. The main purpose of the suggested solution is to further illustrate the semantics that we consider necessary, and to start a discussion. Rights Amplification and future L4 designs (Marcus Brinkmann, Neal Walfield) ============================================================================ Not much can be said about a capability system without first determining how capabilities are represented. The current proposals assume that server objects will be represented by communication end points (more precisely, by the receive end). The send sides of the end points then assume the role of the capability. This is not the only solution. Other primary (kernel) objects following the map/grant/unmap semantics could be used to represent objects and capabilities. Within this framework, the only directly supported operations on such capabilities are map, grant, unmap and IPC. The map operation can be used to delegate the capability, grant can be used to move the capability and unmap to revoke it. The IPC operation allows clients to send messages to an object, for example, to invoke operations on the object. The server can identify the object only when it receives a message on it: on message receipt, the receive side of the end point is presented to the receiving thread. There exists (by assumption) a one-to-one relationship in the server between receive sides of end points and server objects. Thus, given the receive end point, the server can determine to which object any given message was sent. (Note that if you do not use communication end points as object identifiers via a 1:1 relationship, determining to which object a message should go is an open question whose answer depends on how objects identifiers are represented in the first place.) The problem for us is that identifying the object only in the server and only when a message is sent to the object is not sufficient to implement the system we have in mind. In general, we need to be able to know if two capabilities (that is, mappings), are, from a certain perspective, "identical". Identical in this context means that one of the mappings is an ancestor of the other mapping, i.e. that both are associated with the same communcation end point. For our purposes, we don't need to compare _any_ two mappings to the same communication end point; we only need to be able to compare two mappings in the case that one is an ancestor of the other. The following examples will make it clearer. Usage scenario 1: Operations on multiple objects. Consider a server providing multiple objects of the same or different types and operations which require access to more than one of the objects at the same time, i.e. right amplification. The classic example is that of the can and the can opener: an operation such as "open_can (can_opener_t opener, can_t can);" or equivalently "open_can (can_t can, can_opener_t opener);" can only be invoked on either of the two objects but requires capabilities to both. The second object is passed as an argument in the RPC. The server receives the message on one of the two objects which it can readily identify but is now in the peculiar situation of needing to identify the other object. Within the proposed framework, the only low-level mechanism that seems feasible at all here is that the caller _maps_ the second object to the server so as to prove that it has the capability in question. This proof is without meaning if the server cannot establish that this mapped capability is indeed associated with an object it provides; the server must be able to lookup the object based on the mapping from the caller. Usage scenario 2: Reference counting. Modern microkernel based operating systems usually ask for explicit creation and destruction of resources, and rightly so. But at least for legacy support it must be possible to implement reference counting on top of them. Because references must be deallocated automatically on task death, the support for this must be integrated---at least to some extent---into the trusted computing base. Within the initial assumptions, a simple design for a reference counting server readily suggests itself: a reference counting server positions itself---mapping-wise---between a server and its clients. The servers map capabilities to the reference counter which in turn maps them to clients doing the necessary accounting along the way. There are a number of protocols which can be used to copy references from one task to another, etc. The following situation arises when copying a reference from a client, A, to a second client, B: A server, S, has mapped a capability (to a server object) to the reference counter C which has in turn mapped the capability to A. A then maps the capability to B thereby delegating it. B now wants to acquire its own reference and mapping from the reference counter in order to become independent of A. Situation: S -> C -> (1 reference) A -> B Goal: /-> (1 reference) A S-> C \-> (1 reference) B So, B makes an RPC to C: insert_reference (reference_space_t space, cap_t cap, cap_t *new_cap); (The reference space is an object provided by the reference counter and is a name space for all the capabilities to which B has references.) What is important here is that this operation takes a capability as an argument. In this way, B proves that it has access to the capability it got from A. The reference counter will reply with a new mapping that B can use which is independent of the mapping that it got from A - if B then unmaps the mapping it got from A, the situation is symmetrical and the goal accomplished. Shifting perspective from B to the reference counter, the reference counter is in a peculiar position: it is _not_ the server providing the capability CAP. Also, it didn't give a mapping for the capability to client B previously. So it is in a totally different position than the can opener server above: the reference counter sees only send sides, not receive sides, of the communication end points for which it manages references and furthermore it receives capabilities as arguments from tasks to which it didn't previously give mappings. However, there is still some structure left: the reference counter is a mapper of the capability CAP itself: it has a mapping of this capability which it got directly from the server. In addition, the mapping CAP is derived from this mapping in the reference counter itself via A. This is what we want to exploit: we want a way for the reference counter to find the mapping it got from the server for this object based on the mapping it got from B for the same object. The solution: Finding a solution to usage scenario 1 is not too difficult. One approach is protected payloads (a data word chosen by the server) which can be associated with the receive side of a communication end point and which can be read out based on the send side (the mapping, aka capability) if you are sufficiently privileged (i.e., if the receive side resides in the same address space). The protected payload can be set to an internal OID. This solution is inadequate for the second usage scenario: the thread doing the lookup (in the reference counter) did not create the communication end point and thus had no say in the protected payload. Moreover, it shouldn't be able to read it out even if there was one. So, the protected payload idea doesn't seem sufficient. There seems to be a tangible solution though: if there was a system call which allowed the caller to check if a mapping was derived from another mapping in the same address space, then we can use that to "unroll" mapping loops like the one in the first scenario, i.e. Server -> Client -> Server, or in the second, i.e. Server -> Reference Counter -> Client A -> Client B -> Reference Counter. More specifically: Each mapping is identified in the mapper's address space via a virtual address (or index, or slot number, ...). Then there could be a kernel system call vaddr_t map_lookup (vaddr_t addr); which walks up the mapping tree, starting at the mapping entry for ADDR and going to the parent of the current node in each iteration until a mapping in the same address space is encountered. The vaddr of this mapping is returned. Solution in usage scenario 1: Say the send side of the communication point created in the server for the object is located at the vaddr 10. The server records this information in some sort of table. Then the capability is mapped to the client. The client maps it back into the server as part of an RPC. This mapping from the client is installed into the server at vaddr 67. Now the server does: map_lookup (67) -> 10 The map_lookup in the kernel starts from the mapping the server has to the client. It then goes to the parent of that mapping which is the mapping B has from the server. B has a different address space from the server, so the kernel doesn't stop there and continues to the next parent. The next parent is the mapping the server has from the kernel (the communication end point). As address spaces match, the vaddr of this mapping, 10, is returned. The server can then look up the object data for the object associated with the vaddr 10. Solution in usage scenario 2: The server creates a communication end point and maps it to the reference counter which receives it, at say, vaddr 23. The reference counter writes in a table that vaddr 23 corresponds to this server's capability. Now A gets a mapping, delegates it to B, which in turn delegates it to the reference counter which receives it at, for example, vaddr 127. The reference counter does: map_lookup (127) -> 23 The map_lookup operation in the kernel starts with the mapping the reference counter has from the client B. It then walks up the tree first finding the mapping client B has from A, then the mapping client A has from the reference counter and eventually the mapping the reference counter has from the server. The reference counter address space is found and thus the vaddr of this mapping from the server is returned to the reference counter. The reference counter can then record a reference and create a mapping from the mapping "23" to the client B thus creating a symmetrical situation between client B and A. Conclusion ---------- The operation map_lookup achieves our goal of being able to implement the desired functionality. Note that it does not require the kernel to search the whole mapping tree: the tree is only walked from the current node up until the root; it is never walked down or sideways. This means that, for example, if the reference counter has multiple mappings from the server for the same communication point, it will see them all as being distinct (at least it can not establish the identity). It also means that if B gets a direct mapping from the server without going through the reference counter, then the reference counter will not be able to identify this capability as belonging to the same communication point as the mapping it already has. All of these limitations are perfectly acceptable and indeed beneficial. We don't want global identification; we just want to be able to detect mappings _back_ to us which somehow originated from us. I said this should be a system call but in fact that is an implementation detail. It may just as well be done via some other mechanism, for example, in transit during an IPC, if requested. That would actually potentially help. It's unfortunate that the tree has to be walked. Information that is associated strictly with the receiving side ("protected payloads" above) is faster to lookup and has a fixed cost, while walking a tree to the root grows with the depth of the tree. For a negative reply, the whole depth of the tree up to the root has to be walked. In common usage scenarios, however, the tree will not be very deep. I am no expert on mapping databases, so maybe playing around with the data structures can further optimize this path (for example, keeping linked lists per address space in the mapping tree would allow fast lookup of anchestors within the same address space, but my feeling is that maintaining such lists would be more expensive than doing the lookup when it is needed only). There may be security implications in revealing mapping "identities" at all. Maybe this feature needs to be restricted for confined tasks. However, some sort of rights amplification is essential and it is OK to ask for the cooperation of all tasks involved in determining the identity. If for example client A in the reference counter example can deny the map_lookup through its branch of the mapping tree then the reference counter will simply deny its service. This is perfectly acceptable to me; the important thing is that it must not be possible to trick some other task in believing an identity that doesn't exist: to hide identities is fine.

5 34

compiling issue
by Andrew Davenport 15 Jun '05

15 Jun '05

Hello, I attempted to add the following function to Thread: Trap_state *get_trap_state(); it is prototyped as public, and defined below in the interface ipc-exception section of thread.cpp as -- public: inline Trap_state *get_trap_state(); -- inline Trap_state *Thread::get_trap_state() { return (Trap_state*)this->_utcb_handler; } -- I then try to use it in Thread::do_send (in thread-ipc.cpp) I get the following compile error message: -- thread-ipc.o(.text._ZN6Thread7do_sendEPS_10L4_timeoutP13Sys_ipc_frame+0x17): In function `Thread::handle_page_fault_pager(unsigned int, unsigned int)': /home/adaven/20050523_fiasco_cvs/l4/kernel/fiasco/build/auto/context.h:479: undefined reference to `Thread::get_trap_state()' -- If anyone could shed some light into this, I would appreciate it. Thanks, Andrew

2 1

Still some boot problem
by fabs0028＠free.fr 15 Jun '05

15 Jun '05

thanx for the answers. As you said, i forgot the vga in linux. I added the l4ser with the vga so now i got all the boot messages. For the panic, it was about my filesysten that the kernel wasn't able to mount so now it works. But now i got a warning saying that he can't open a terminal and after i go blind. Correct me if i'm wrong but i do think i need to use either dope or con or have i once more forgotten a thing in the kernel ?. One more question ... will X runs as if i was on a legacy linux ? (i think so but i'm not sure). Thanx a lot once more. Fabien Chaillou

2 1

l4vfs_log
by Tiago Jorge 14 Jun '05

14 Jun '05

hello... in my work for debug purpose it would be handy to output the log to a file. will l4vfs_log do the job? if so, i can't understand the example of starting the server. could someone send me an example how to start and use this log server? thanks Tiago

2 1

Still some boot problem
by fabs0028＠free.fr 14 Jun '05

14 Jun '05

Hello well my system is not far from being ready but i have another problem once more. L4linux boots, it prints his messages and then it hangs and never go further, here is the messages : l4lx | ======> L4Linux 2.6 starting... <======== l4lx | Binary name: vmlinuz26 l4lx | Kernel command line (3 args): ro root=/dev/VolGroup00/LogVol00 rhgb l4lx | My DMphys is at 07.00 l4lx | My region mapper is at 0c.00 l4lx | My code starts at 0x003ff000 and ends at 0x006d71a8 [2912 KiB]. l4lx | Semaphore thread ID: 0c.01 l4lx | Areas: l4lx | Text: 003ff000 - 005fc000 [2036kB] (a bit longer) l4lx | Data: 005fc000 - 0063d580 [261kB] l4lx | Initdata: 00640000 - 0066a000 [168kB] l4lx | BSS: 0066a008 - 006d71a8 [436kB] l4lx | l4lx_thread_create: Created thread 0c.03 (CLI SEM thread) l4lx | Using tamed mode. l4lx | l4lx_thread_create: Created thread 0c.04 (Linux server) l4lx | main thread will be 0c.04 l4lx | l4env_register_pointer_section: addr = 3ff000 size = 2539520 l4lx | with-init: virt: 0x003ff000 to 0x0066afff [2480 KiB] l4lx | Noncontinuous region for with-init l4lx | with-init: Number of physical regions: 4, 2539520 Bytes l4lx | with-init: 1: Phys: 0x01134000 to 0x011a7000, Size: 6061788 l4lx | with-init: 2: Phys: 0x01417000 to 0x01500000, Size: 6061788 l4lx | l4env_linux_startup thread 4. l4lx | with-init: 3: Phys: 0x01339000 to 0x01400000, Size: 6061788 l4lx | with-init: 4: Phys: 0x012b7000 to 0x01300000, Size: 6061788 l4lx | main thread: received startup message. l4lx | Main memory size: 32MB l4lx | Main thread running, waiting... l4lx | Mainmem DS id: 44 l4lx | mainmem: virt: 0x006d8000 to 0x026d7fff [32768 KiB] l4lx | mainmem: Number of physical regions: 1, 33554432 Bytes l4lx | mainmem: 1: Phys: 0x030f0000 to 0x050f0000, Size: 6061522 l4lx | Filling lower ptabs... l4lx | Done (886 entries). l4lx | l4x_setup_ti_thread_stack: ti = 0x905fe000 l4lx | l4lx_thread_create: Created thread 0c.05 (IRQ0 (Timer)) l4lx | DOpE is not registered at names! l4lx | l4x_setup_ti_thread_stack: ti = 0x906fe000 l4lx | l4lx_thread_create: Created thread 0c.06 (IRQ17) l4lx | l4x_setup_ti_thread_stack: ti = 0x907fe000 l4lx | l4lx_thread_create: Created thread 0c.07 (IRQ16) l4lx | l4x_setup_ti_thread_stack: ti = 0x908fe000 l4lx | l4lx_thread_create: Created thread 0c.08 (IRQ15) l4lx | l4x_setup_ti_thread_stack: ti = 0x909fe000 l4lx | l4lx_thread_create: Created thread 0c.09 (IRQ14) l4lx | l4x_setup_ti_thread_stack: ti = 0x90afe000 l4lx | l4lx_thread_create: Created thread 0c.0a (IRQ13) l4lx | l4x_setup_ti_thread_stack: ti = 0x90bfe000 l4lx | l4lx_thread_create: Created thread 0c.0b (IRQ12) l4lx | l4x_setup_ti_thread_stack: ti = 0x90cfe000 l4lx | l4lx_thread_create: Created thread 0c.0c (IRQ11) l4lx | l4x_setup_ti_thread_stack: ti = 0x90dfe000 l4lx | l4lx_thread_create: Created thread 0c.0d (IRQ10) l4lx | l4x_setup_ti_thread_stack: ti = 0x90efe000 l4lx | l4lx_thread_create: Created thread 0c.0e (IRQ9) l4lx | l4x_setup_ti_thread_stack: ti = 0x90ffe000 l4lx | l4lx_thread_create: Created thread 0c.0f (IRQ8) l4lx | l4x_setup_ti_thread_stack: ti = 0x910fe000 l4lx | l4lx_thread_create: Created thread 0c.10 (IRQ7) l4lx | l4x_setup_ti_thread_stack: ti = 0x911fe000 l4lx | l4lx_thread_create: Created thread 0c.11 (IRQ6) l4lx | l4x_setup_ti_thread_stack: ti = 0x912fe000 l4lx | l4lx_thread_create: Created thread 0c.12 (IRQ5) l4lx | l4x_setup_ti_thread_stack: ti = 0x913fe000 l4lx | l4lx_thread_create: Created thread 0c.13 (IRQ3) l4lx | l4x_setup_ti_thread_stack: ti = 0x914fe000 l4lx | l4lx_thread_create: Created thread 0c.14 (IRQ1) and then nothing happens. i feel a bit lost. there is something else, the kernel calls printk but nothing appears on screen, maybe it is just because the messages are not supposed to be printed but i think it is weird. It seems that the linux server has gone in l4x_blink and sleeps forever but i can't find out where it come from (Is it possible to follow the execution with jdb ?) Thanx a lot for your help. Fabien Chaillou

2 1

Memory problems concerning DDE and FLIPS
by Tiago Jorge 13 Jun '05

13 Jun '05

hello... i'm trying to put project reliable and i'm testing now the possibility of using the network for long periods of time with FLIPS. but when i do a considerable amount of sendto's it gives me the following error: [C.A]dde_linux/lib/src/mm.c:117: __more_kcore(): Error: out of memory i've seen that this error ocurrs when something in DDE is out of memory. i presume the driver's buffers. What can i do to increase this memory? is this possible? or is it something not flushing some buffers in a correct way? thanks Tiago

2 4

unhandled trap problem
by fabs0028＠free.fr 13 Jun '05

13 Jun '05

Hello, first i 'd like to thank you one more time for you support. It seems that my path to a proper l4linux is coming to an end but i still have one problem: at boot time when launching l4linux i got this problem : l4lx | mainmem: Number of physical regions: 1, 33554432 Bytes l4lx | mainmem: 1: Phys: 0x03182000 to 0x05182000, Size: 6175342 l4lx | Filling lower ptabs... l4lx | Done (885 entries). l4lx | l4x_setup_ti_thread_stack: ti = 0x905fe000 l4lx | l4lx_thread_create: Created thread 0c.05 (IRQ0 (Timer)) KERNEL: c.4 (tcb=c0302000) killed: Unhandled trap EAX ffffffff EBX 0071e000 ECX 00000064 EDX 0071d000 ESI 0100e3c0 EDI 0061f124 EBP 00665ec4 ESP 00665ec0 EIP 004e00dc EFLAGS 00013296 CS 001b SS 0023 DS 0023 ES 0023 FS 0023 GS 0043 trapno 13, error 00000000, from user mode (internal event regarding GDT entry no. 0x00) i want precise that i'm running fiasco and not fiasco-ux. so i disassembled at the given eip and i found that : ... linux-env/l4linux-2.6/arch/l4/lib/arch-i386/../../../i386/lib/mmx.c:158 004e00d9 sfence ... linux-env/l4linux-2.6/arch/l4/lib/arch-i386/../../../i386/lib/mmx.c:161 004e00dc mov %cr0,%eax 004e00df or $0x8,%eax 004e00e2 mov %eax,%cr0 004e00e5 pop %ebx 004e00e6 leave 004e00e7 ret so the problem occurs when the value of eax is put into cr0. i took a look into the source, the error was in static void fast_clear_page(void *page) and the line was kernel_fpu_end(); which is a macro for do { stts(); preempt_enable(); } while(0) in i387.h and stts is also a macro : #define stts() write_cr0(8 | read_cr0()) and we got those last two macro : #define read_cr0() ({ \ unsigned int __dummy; \ __asm__( \ "movl %%cr0,%0\n\t" \ :"=r" (__dummy)); \ __dummy; \ }) #define write_cr0(x) \ __asm__("movl %0,%%cr0": :"r" (x)); I don't know what the problem is, i thought i had left a bad option in my kernel configuration but i checked it and i saw nothing wrong for me (maybe i didn't see it). Thanx for your help. Fabien Chaillou

2 1

Problem booting l4linux
by fabs0028＠free.fr 10 Jun '05

10 Jun '05

Hello I 'm trying to boot my fresh l4linux, i used the following entry in grub as adam previously told me to. title L4/Linux root (hd0,0) kernel /l4linux/rmgr -sigma0 task modname "L4Linux task" task modname "bmodfs" module module module modaddr 0x02000000 module /l4linux/fiasco -nowait -nokdb -serial_esc -comspeed 115200 -comport 1 module /l4linux/sigma0 module /l4linux/names module /l4linux/log module /l4linux/dm_phys module /l4linux/simple_ts -t 300 module /l4linux/l4io --noirq module /l4linux/bmodfs module /l4linux/libloader.s.so module /l4linux/run-l4 module /l4linux/vmlinuz26 module /l4linux/l4exec module /l4linux/loader --fprov=BMODFS run-l4 It starts but i get the following error messages : simplets|configured for 300 tasks bmodfs | L4RM: [PF] read at 0x00000000, eip 0122c495, src A.01 bmodfs | [A.0] l4rm/lib/src/pagefault.c:78:__unknowm_pf(): bmodfs | unhandled page fault It seems to be a problem with a null pointer and i'm sure it is a problem in my grub file but i don't know what's wrong. I tried to change some options but i always get this problem but it is not always the same server that crashes, it depends on my options. Thanx for the help Fabien Chaillou

3 3

Loading shared objects in an l4env_freebsd application
by Derick Swanepoel 10 Jun '05

10 Jun '05

Hi again, I need to load shared objects in my application. I've got .so loading working in a loader-mode app, but my app uses the l4env_freebsd mode so I cannot link against libloader.s.so. I've tried to link against libloaderif.a, but the l4loader_attach_relocateable() function is only available in libloader.s.so. Any help would be appreciated, Derick

2 7

questions on L4Env and libraries for development on pistachio
by Jayesh Salvi 10 Jun '05

10 Jun '05

I am looking for libraries to do coding on pistachio. As I understand L4Env gives a bunch of libraries - memory management libraries (dm_phys,...), l4io, etc. Could someone answer these questions: 1. From L4Env's docs I see it being used only with fiasco source code. Haven't come across any project that uses L4Env with pistachio. Any dependencies that I don't know of? If not are there any examples? 2. I want libraries for some basic functions - malloc, free, printf, etc. L4Env needs oskit, l4linux2.2 and fiasco L4 kernel. Aren't there any lightweight ways of getting such libraries for L4? Can parts of L4Env used seperately in pistachio tree? 3. I came across libCLight library which is the light implementation of libc. I could get it compiled in my pistachio tree, as done in IoL4 project. Can anyone compare using malloc in libCLight and using DMPhys of L4Env? Hope these questions are not that naive. Thanks in advance. -- Jayesh

4 5

Grub problem
by fabs0028＠free.fr 09 Jun '05

09 Jun '05

Hello, i'm trying to create a l4linux system based on l4linux 2.6 and fiasco. i builded l4linux with l4env and fiasco from scratch with no problem but when i wanted to launch it i had problems with the grub version (gnu grub 0.95). I took your grub version as i was advised but i can't build it i have some problems, mainly with a reference to memcpy in some files in the stage2 directory, but what's weird is that there's no references to that fonction in the concerned files. For the record here is my grub menu.lst concerning l4linux title L4/Linux root (hd0,0) kernel /l4linux/rmgr task modname "bmodfs" module module module module /l4linux/fiasco module /l4linux/bmodfs module /l4linux/libloader.s.so module /l4linux/run-l4 module /l4linux/vmlinuz26 module /l4linux/loader --fprov=BMODFS run-l4 thanx for your help

2 3

gettimeofday(2) and time(2)
by Derick Swanepoel 09 Jun '05

09 Jun '05

Hi all, I would like to get the current time as reported by gettimeofday(2) and time(2). However, neither of these functions seem to work in L4. gettimeofday() fills in the timeval struct with random values and time() always returns -1. What is the correct way to get the time in seconds since the Epoch in L4? Thanks in advance, Derick

3 7

Re: [Fwd: Re: gettimeofday(2) and time(2)]
by Julian Grizzard 09 Jun '05

09 Jun '05

> use the RTC server. $(L4DIR)/pkg/rtc. Is $(L4DIR)/pkg/rtc part of the fiasco project CVS? If so, how do you check it out? Contents of my $(L4DIR)/pkg/ directory from 20050523 CVS: $ ls build/l4/pkg/ COPYING CVS hello l4sys Makefile rmgr crtx demangle l4lthread l4util oskit_support sigma0 Thanks! -Julian

3 7

Status of the fiasco project
by fabs0028＠free.fr 09 Jun '05

09 Jun '05

Hello everyone, i'm a bit new in the world of L4. It is really interesting but it seems a wide world as well. I'd like to know if there will be a new version of fiasco in the near future and the main goal you are wanting to achieve for this hypothetic new version. Fabien Chaillou

2 1

l4linux2.4 System Call Emulation question
by Andrew Davenport 07 Jun '05

07 Jun '05

Hi, where in l4 does an exception (int 0x80) get trapped and turned into an appropriate l4 ipc and sent to l4linux? for instance: if (from an l4linux program), i do a system call like this (in assembly) mov bx, 0x20 mov ax, 0x10 int 0x80 where will i see 0x10 and 0x20 (the syscall parameters) inside the l4 IPC ?? Thanks very much in advance -andrew

2 1

l4linux question
by Andrew Davenport 04 Jun '05

04 Jun '05

Hello, I have a fiasco l4/l4linux system setup. I want to eventually log all linux system calls from within the fiasco kernel (via thread::sys_ipc and thread::shortcut_ipc). I am curious: How does a linux system call get translated into an l4 ipc ? Thanks, Andrew Winter Davenport

2 1

TFTP server and E1000 problem
by Leon Brits 04 Jun '05

04 Jun '05

Hi all, I've just received an Intel E1000(82545GM) NIC to make work with the TFTP server. The problem is that it does not seem to receive packets when connected to a GigE switch. It does work with a Fast Ethernet switch. The switches are from the same manufacturer. I do see the initial DHCP/BOOTP message send out, so I added some debug code to the rx-polling routine and it does not ever receive anything. I've looked on the Etherboot-project's mailing list and found some comments to a similar error back in 2002 but no mention of a reason or a fix. Any suggestions? Thanks Leon

2 1

Debugging an L4 task
by Derick Swanepoel 02 Jun '05

02 Jun '05

Hi, I am trying to debug an L4 task that double pagefaults before reaching the main function. How should one use the debugger to run a task so it can be debugged without having to break into the debugger later? The backtrace doesn't seem very useful because it looks like a stack overflow due to infinite recursion. Here is the loader output: exec | testtask: Loading exec | testtask: Has no dynamic info exec | testtask: Saved 50936 bytes of symbols exec | testtask: "libloader.s.so" not in library list loader | testtask: Starting sigma0-style application exec | testtask: Packed 37981 bytes of symbols exec | testtask: Packed 60324 bytes of lines loader | testtask,#11: Entry at 00009c7c => 01600000 loader | testtask,#11: Started loader | testtask,#11: Double PF (w) at 0c776bec eip 016290bf (11.00) Here is the backtrace: backtrace (thread 11.00, fp=01629068, pc=016290bf): #1 016290bf : capdigits + 0x12 #2 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #3 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #4 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #5 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #6 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #7 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #8 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #9 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #10 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #11 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #12 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #13 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #14 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #15 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #16 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #17 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #18 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #19 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #20 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #21 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #22 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #23 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #24 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #25 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #26 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #27 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #28 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #29 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #30 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #31 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #32 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #33 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #34 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #35 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 #36 01604dca : outs + 0x2a /home/derick/DROPS/l4/pkg/log/lib/src/logliblinux.c:22 #37 01604970 : flush + 0x20 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:47 #38 01604a4f : printchar + 0xcf /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:71 #39 01604c56 : LOG_fputs + 0x26 /home/derick/DROPS/l4/pkg/log/lib/src/log_printf.c:148 --kernel-bt-follows-- (don't trust w/o frame pointer!!) #1 f0005950 #2 f0004c7e #3 f0009e01 #4 f0009e01 #5 f00053ee #6 f0009a65 #7 f000b3fa #8 f00049ce #9 f000b767 #10 f00086e3 #11 f0004084 #12 f0006931 #13 f00253a2 Thanks in advance, Derick

2 3

IPCs
by Andrew Davenport 02 Jun '05

02 Jun '05

Hello, I am trying to make a simple IPC logger in L4 (by modifying the kernel). I want to eventually log src, dest, and contents of the message. Where would be most effective place in the l4 kernel to do this, and how should I go about getting the message contents -- eg registers, flex pages or strings ? Thanks, Andrew -- Andrew Winter Davenport Georgia Institute of Technology College of Computing www.prism.gatech.edu/~gtg259m

2 1