- l4-hackers - example.com Site

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

Old and new L4 APIs (was Re: L4Hurd at Sourceforge)
by Michael Hohmuth 30 Oct '01

30 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes: > If the L4 people could provide us with a coherent view of the current > (and upcoming) APIs and C-Bindings, that would be _great_! (hint, hint!) The most coherent view on current APIs is available at <URL:http://os.inf.tu-dresden.de/L4/bib.html>. The L4 people in charge of the new L4 API (the Karlsruhe guys) have decided to circulate the upcoming specification in a limited way first to keep discussion short and efficient. They deemed this necessary because they felt that the current draft is not self-explanatory enough to be consumed by larger audiences without overloading its developers with questions. Let's respect them regarding their decision. In the meantime (and in general), I suggest using library APIs that will remain unmodified regardless of kernel version. Please have a look at the upcoming L4 environment, which exists now and is relatively well documented <URL:http://os.inf.tu-dresden.de/L4/bib.html#l4env>. A release is forthcoming as soon as the L4Env developers feel that their users understand and are comfortable with their libraries. Try giving them this impression! Or even better: Help them by writing a user's guide for L4Env! Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: vk_l4 -- CVS Setup
by Farid Hajji 30 Oct '01

30 Oct '01

> At Thu, 25 Oct 2001 12:01:56 +0200, > Christian Ceelen wrote: > > Where could I find these research papers? > > http://www.netbsd.org/Documentation/kernel/uvm.html > http://www.usenix.org/events/usenix99/full_papers/cranor/cranor_html/ > http://www.ccrc.wustl.edu/pub/chuck/psgz/diss.ps.gz > http://www.ccrc.wustl.edu/pub/chuck/psgz/osdi99.ps.gz > http://www.ccrc.wustl.edu/pub/chuck/psgz/disstalk.ps.gz > > Okuji 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 ;-). -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.

1 0

L4 device-driver framework (was Re: vk_l4 -- CVS Setup)
by Michael Hohmuth 29 Oct '01

29 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes in l4-hurd: > [...] We'll probably also need glue code from OSKit to drop in the > driver framework from Michael. To clarify: There are two L4 device-driver frameworks that are currently in use, neither of which is ``Michael's framework.'' - One is a port of the OSKit to L4. It allows running OSKit applications on top of L4 in user mode, including applications that use OSKit's device drivers (which are mostly inherited from FreeBSD and Linux). It can be used to get applications up and running in short time on x86 machines, but it is somewhat slow, produces huge binaries (most of the time, the OSKit startup code links in *all* device drivers of a class) and is not portable (the OSKit really only runs on x86). Our distribution (available as part of our "l4" CVS module) includes a number of example programs lifted straight from the set of examples that came with the OSKit, including a "finger" client and a filesystem example. Here is the technical report I wrote on it: <URL:http://os.inf.tu-dresden.de/~hohmuth/prj/oskit-l4.ps.gz> - The other framework is a new development that is intended to fix the OSKit problems I mentioned, developed mainly by Christian Helmuth and Lars Reuther. This framework is intended to allow dropping the source code of one Linux driver inside it, recompiling, and ending up with a working L4 device driver. This framework does not use the OSKit (AFAIK), but is based on our new L4 environment, ``L4Env''. A prototype for character-device drivers exists, but hasn't been released yet. Preliminary L4Env docs: <URL:http://os.inf.tu-dresden.de/L4/bib.html#l4env> A description of the device-driver framework (Christian's diploma thesis, in German only): <URL:http://os.inf.tu-dresden.de/~ch12/sub/diplom.ps> Please bug the DROPS developers concerning releasing this stuff. :-) Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Is this list active?
by Ian Duggan 23 Oct '01

23 Oct '01

Is this list still active? Are there other L4 lists that I should be on as well? -- Ian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian(a)ianduggan.net http://www.ianduggan.net

2 1

Re: Writing device drivers for L4 (was Re: Hurd/Mach on L4)
by Michael Hohmuth 14 Oct '01

14 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes: > > Currently, some of my colleagues are working on a framework that > > allows you to (more or less) drop a Linux driver in a preconfigured > > source tree and get a working driver that runs on the x86 L4 kernels > > (L4/x86, Fiasco, L4KA). This framework, which will work with the > > L4Env environment we're developing, is not quite ready yet, but it > > might be worth the wait. > > Will the drivers run in userland on top of a vanilla L4 kernel? Yes, they will. > I'm wondering wether it would be possible to use (RPC?) the driver > tasks directly from OS personalities like L4Linux, (L4BSD if someone > wants to repeat the Lites experience on L4 ;-)) or the Hurd, possibly > even simultaneously? Yes. We have been working on stub drivers for L4Linux that use external user-level drivers concurrently with (non-Linux) tasks. I'm not sure right now which stub drivers we currently provide, but I believe we already support console drivers and block-device drivers. > > As an alternative, consider using the OSKit. We have developed a > > compatibility library that allows you to run applications using the > > OSKit (including the OSKit's device drivers) on top of L4. This work > > is a bit unpolished and the drivers are slow, but it's quite easy to > > Good point. However, wouldn't it be necessary to link the driver > libs to the Kernel? This is exactly what we want to avoid in the > OSKit-Mach case sometime in the future (*Sigh*). No, the drivers run completely on user level. The OSKit has well-defined interfaces for low-level OS services such as IRQ allocation and delivery. Reimplementing these interfaces for a target system such as L4 (in particular parts of liboskit_dev and liboskit_kern) makes it possible to port OSKit drivers to the target system. OSKit drivers do not care whether they run on user level or in kernel mode if all services they expect from liboskit_dev and liboskit_kern are available. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0