l4-hackers

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

2 participants
2880 discussions

OSKit-Problems with newer glibc
by imi＠wh9.tu-dresden.de 16 Jan '02

16 Jan '02

Hi Are there any reported solutions for compiling the oskit1.0 that comes with l4 with installed glibc 2.2.4 or newer? On my machine (Debian "sid", gcc 2.95.4) it throw a linker error while linking unix/linux/sbrk-hack.o together with libc.a because duplicate symbol __libc_multiple_libcs. The sbrk-hack's only purpose seems to be defining these global variable (as an int). Maybe this was an error in libc and got fixed in 2.2.4? However when I compiled under glibc 2.1.3-10 (and gcc 2.95.2) it works... -- Immanuel Scholz, PGP: (Work 0x9216F1E7, Home 0x3B5DC02D)

1 0

2nd release of L4Ka/Hazelnut
by Uwe Dannowski 14 Dec '01

14 Dec '01

Hi L4 hackers and users, after a long wait it's again time to announce a new release of L4Ka/Hazelnut. L4Ka/Hazelnut still implements the L4 Version X.0 API on x86 and ARM processors. This time around, however, it outperforms Jochen's x86 assembly kernel. Parts of the kernel have also been redesigned for better portability. Among the goodies added since the last release are: o Small Address Spaces o IPC FastPath(tm) o FPU virtualization o Enhanced kernel debugger (e.g., embedded disassembler and profiling support) o Pentium4 support o One year's worth of bugfixes For more information please visit http://l4ka.org/.

1 0

RE: l4 for 386
by Sebastian Schoenberg 08 Nov '01

08 Nov '01

Well, sort of or not. You have a mirrored region for kernel- accessed read-only memory regions where the kernel potentially might write to. You don't need a mirrored region for all writable pages. Seb > -----Original Message----- > From: Espen Skoglund [mailto:esk@ira.uka.de] > Sent: Mittwoch, 7. November 2001 13:31 > To: Sebastian Schoenberg > Cc: jhuntnz(a)users.sourceforge.net; l4-hackers(a)os.inf.tu-dresden.de > Subject: RE: l4 for 386 > > > [Sebastian Schoenberg] > > This can be done by using different regions for read and write > > access. For tasks where the write-protection is neccesary, a page > > is mapped only to the writeable area if the page is writable in the > > page-table. > > I'm not sure I know what you mean here. Are you suggesting that we > divide the user-accessible virtual memory into two equally sized > mirrored regions; one for read-only and one for read-write? > > eSk >

1 0

RE: l4 for 386
by Sebastian Schoenberg 07 Nov '01

07 Nov '01

This can be done by using different regions for read and write access. For tasks where the write-protection is neccesary, a page is mapped only to the writeable area if the page is writable in the page-table. The task is to find all relevant writes in the current version. Seb > -----Original Message----- > From: Michael Hohmuth [mailto:hohmuth@innocent.com] > Sent: Mittwoch, 7. November 2001 12:35 > To: jhuntnz(a)users.sourceforge.net > Cc: l4-hackers(a)os.inf.tu-dresden.de > Subject: Re: l4 for 386 > > > Jonathan Hunt <jhuntnz(a)users.sourceforge.net> writes: > > > Yes I would but interested in porting this to a 386. Could anyone > > give me some more information on what would be required to > > change. (The FAQ is rather brief). I understand the the CR0::WP bit > > enables an exception when a fully privileged task (such as the > > kernel task) writes to a read-only page but when does this happen > > that I can check explicitly for it? > > Offhand I can think of two places that rely on page faults when > writing to write-protected pages: > > - When reading from a nonexisting thread's thread-control block (TCB), > the TCB's virtual-memory region is backed by a read-only zero-filled > page. This page gets replaced with a newly-allocated page only when > a write access occurs. This mechanism is intended to prevent > malicious threads from causing the kernel to allocate hundreds of > pages by attempting to send IPC to (or otherwise modify) nonexisting > threads. > > In a first 386 version, this protection mechanism can just > be disabled. > > - In memory-copying IPC operations (and some other operations that > write to the user address space, like exception delivery), > the kernel > relies on page faults when accessing write-protected user pages. > > This could be approximated by checking for write permission in the > copy operation, like Linux does. > > Michael > -- > hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de > http://home.pages.de/~hohmuth/ > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers >

3 2

Re: l4 for 386
by Michael Hohmuth 07 Nov '01

07 Nov '01

Jonathan Hunt <jhuntnz(a)users.sourceforge.net> writes: > Yes I would but interested in porting this to a 386. Could anyone > give me some more information on what would be required to > change. (The FAQ is rather brief). I understand the the CR0::WP bit > enables an exception when a fully privileged task (such as the > kernel task) writes to a read-only page but when does this happen > that I can check explicitly for it? Offhand I can think of two places that rely on page faults when writing to write-protected pages: - When reading from a nonexisting thread's thread-control block (TCB), the TCB's virtual-memory region is backed by a read-only zero-filled page. This page gets replaced with a newly-allocated page only when a write access occurs. This mechanism is intended to prevent malicious threads from causing the kernel to allocate hundreds of pages by attempting to send IPC to (or otherwise modify) nonexisting threads. In a first 386 version, this protection mechanism can just be disabled. - In memory-copying IPC operations (and some other operations that write to the user address space, like exception delivery), the kernel relies on page faults when accessing write-protected user pages. This could be approximated by checking for write permission in the copy operation, like Linux does. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

l4 for 386
by Jonathan Hunt 07 Nov '01

07 Nov '01

Hi, Is there a version of l4 for a Intel 386. I am wanting to experiment with l4 and have a spare i386 to play with but nothing else. None of the "virtual machine" solutions look very nice. If not is anybody working on a version? Any plans? Thanks, Jonny -- Jonathan Hunt (The Real Jonathan Hunt) <jhuntnz(a)users.sf.net> Jabber at jhuntnz(a)jabber.com "He is no fool who gives what he cannot keep to gain what he cannot lose." Jim Elliot

3 3

How to unsubscribe
by Li Bing 05 Nov '01

05 Nov '01

Dear all, Please tell me how to unsubscribe the list. I am very appreciated for your help! LB _.--"""--._ .' '-. `. __/__ (-. `\ \ /o `o \ \ \ \ _\__.__/ )) | | ; .--;" | | \ ( `) | | \ _|`---' .' _, _| | `\ '`_\ \ '_,.-';_.-`\| \ \_ .' '--'---;` / / |\ |_..--' \ \'-'.' .--'.__/ __.-; `"` (___...---''` \ _/_ \ /ASU\ libing(a)asu.edu \___/ 480-965-9038(L), 480-829-8492(H) http://www.public.asu.edu/~libing

2 1

Why distinction between task and thread ?
by Robert Kaiser 05 Nov '01

05 Nov '01

Hello all, this may be a stupid question, but... It seems to me that address spaces and activities (to avoid the words "task" and "thread") are othogal concepts. What is the reason for L4 to not keep them seperate in it's API ? (i.e. there is task_new to create an activity _and_ an address space and there is lthread_ex_regs to create an activity in an already existing address space). It would seem a lot "cleaner" to me if there was one system call to create an address space (without any activity in it) and another one to create an activity, specifying as a parameter the address space in which it will execute. Is there a reason (perhaps security ?) why it wasn't done like that in L4 ? Thanks for any insights. Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Am Pfaffenstein 14 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10

2 1

tftp problems
by Ian Duggan 05 Nov '01

05 Nov '01

I'm having problems getting L4 to boot using grub and tftp. My grub config looks like this: title = ChacmOS on Sopwith kernel = (nd)/tftpboot/chacmos/rmgr -sigma0 -roottask module = (nd)/tftpboot/chacmos/x86-kernel module = (nd)/tftpboot/chacmos/sigma0 module = (nd)/tftpboot/chacmos/booter module = (nd)/tftpboot/chacmos/memsvr module = (nd)/tftpboot/chacmos/namesvr module = (nd)/tftpboot/chacmos/ext2fs module = (nd)/tftpboot/chacmos/ramdisk module = (nd)/tftpboot/chacmos/shell It gets as far as retrieving rmgr via tftp (I see it get requested in the logs), but the machine reboots itself as it is loading the rmgr image. It prints out the "[Multiboot-elf blah blah" stuff and does a reboot before anything related to x86-kernel is printed to the screen. This happens very quickly. If I move the first two files to the boot floppy I am using, things boot fine. This config works: title = ChacmOS on Sopwith (Floppy) kernel = (fd0)/rmgr -sigma0 -roottask module = (fd0)/x86-kernel module = (nd)/tftpboot/chacmos/sigma0 module = (nd)/tftpboot/chacmos/booter module = (nd)/tftpboot/chacmos/memsvr module = (nd)/tftpboot/chacmos/namesvr module = (nd)/tftpboot/chacmos/ext2fs module = (nd)/tftpboot/chacmos/ramdisk module = (nd)/tftpboot/chacmos/shell There is something in the grub/tftp boot process that differs from what it does when loading the files from floppy that causes problems. It seems that maybe it is starting to execute stuff before it has everything in place? I am using grub 0.90 from the Debian source. Any ideas? What else can I do to try to track down the problem? --Ian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian(a)ianduggan.net http://www.ianduggan.net

2 1

Re: vk_l4 -- CVS Setup
by Lars Reuther 30 Oct '01

30 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes: > BTW, is anyone in the L4 community currently implementing a pager task > that would resemble Mach-VM or, even better, UVM? This is of general > interest to all developers of L4-based OS-personalities, not just > l4-hurd. Getting all the memory from sigma0 upon startup is not very sexy ;-). The current VM management model of L4Env is roughly based on the ideas described in <ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Aron_PJLED_01.ps.gz>. See also the documentations for the L4 Region Mapper and Dataspace Manager at the L4 Developer's Bibliography mentioned by Michael. Lars -- Dipl.-Inf. Lars Reuther Dresden University of Technology Department of Computer Science Operating Systems Research Group Phone: +49 (351) 463-38401 Fax: +49 (351) 463-38284 reuther(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/~reuther/

1 0

Jump to page:

2025

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