l4-hackers

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

2827 discussions

A few questions
by Geoff Humphreys 20 Oct '99

20 Oct '99

Hello. I have been writing my own microkernel using ideas from L4 and other kernels. I am curious as to whether or not there would be an appreciable performance increase if the L4 system calls were split up into multiple calls. For example, the IPC call is be used to send messages, recieve messages, and to do RPC. Wouldn't it be faster if each of those were separate system calls (since it would require less if-then logic and bit manipulation)? Is there any reason not to do this? In addition, I am seeking well-commented, easy to understand scheduling algorithms or detailed descriptions of them. Right now I am using a nice, simple round-robin scheduler that doesn't even take priorities into account. It is very efficient, however. 8-) Also, does L4 have any support for semaphores? I was unable to find anything in the documentation. Thanks Geoff ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: A few questions
by Jean Wolter 20 Oct '99

20 Oct '99

"Geoff Humphreys" <xsaber0(a)hotmail.com> writes: > > Hello. I have been writing my own microkernel using ideas from L4 and other > kernels. > > I am curious as to whether or not there would be an appreciable performance > increase if the L4 system calls were split up into multiple calls. For > example, the IPC call is be used to send messages, recieve messages, and to > do RPC. Wouldn't it be faster if each of those were separate system calls > (since it would require less if-then logic and bit manipulation)? Is there > any reason not to do this? Maybe you should have a look at Jochen's micro kernel papers on our L4 page (SOSP93, SOSP95). One point was to combine the various ipc operations into one system call to reduce the number of 'kernel boundary crossings'. You add one simple if and remove an expensive switch from user to kernel and back. So this actually increases performance. > Also, does L4 have any support for semaphores? I was unable to find > anything in the documentation. There are no semaphores inside L4. All semaphores are implemented on user level. Jean -- I get up each morning, gather my wits. Pick up the paper, read the obits. if I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. Peete Seeger

1 0

Looking for L4 tutorials and documentation
by Geoff Humphreys 18 Oct '99

18 Oct '99

Hello. I am looking for L4 tutorials and documentation. I have the L4 reference manual for the 486/Pentium/Pentium pro, but I would like to find documentation with in-depth examples and benchmarks. Are such documents available, and if so, where? Thanks Geoff Humphreys ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: RMGR-Extension to control I/O access
by Jean Wolter 17 Oct '99

17 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > Hello, > > I don´t know very much about the i386-processor and Fiasco, therefore > I would like to know if the following RMGR/Fiasco extensions are possible. > > 1) As default, no task has I/O port access. (CPL > IOPL or I/O permission > bitmap pointer invalid) > > 2) A task asks via IPC the RMGR for I/O port access, e.g. port=0x80, length=4. > > 3) The RMGR checks, if port access can be granted. If yes, the RMGR decreases > the tasks CPL and/or changes the tasks I/O permission bitmap. > > ==> Task is able to access port 0x80 - 0x83. > > The main question: I don´t know if a task is able to change the CPL > or the I/O permission bitmap of another task. That is exactly what io flex pages are designed for. Initially sigma0 has access to all io ports and can use io flex pages to grant port access to other task. If sigma0 grants access a subset of the io address space (adressses which are accessed by in/out instructions) the task gets an io permission bitmap. If sigma0 (or someone else) grants access to the whole io address space l4 changes the iopl so that any thread in this task can access any port and can even disable interrupts. So the only missing feature is an implementation of io flex pages. Jean -- I get up each morning, gather my wits. Pick up the paper, read the obits. if I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. Peete Seeger

2 1

RMGR-Extension to control I/O access
by Christian Stueble 15 Oct '99

15 Oct '99

Hello, I donŽt know very much about the i386-processor and Fiasco, therefore I would like to know if the following RMGR/Fiasco extensions are possible. 1) As default, no task has I/O port access. (CPL > IOPL or I/O permission bitmap pointer invalid) 2) A task asks via IPC the RMGR for I/O port access, e.g. port=0x80, length=4. 3) The RMGR checks, if port access can be granted. If yes, the RMGR decreases the tasks CPL and/or changes the tasks I/O permission bitmap. ==> Task is able to access port 0x80 - 0x83. The main question: I donŽt know if a task is able to change the CPL or the I/O permission bitmap of another task. Ciao, Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Question about IO-fpages
by Jean Wolter 15 Oct '99

15 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > It is said that always the complete IO space should be specified as > > receive fpage, why? > ? With flexpages you can map a page to an arbitrary address by specifying an according receive flex page. You are not allowed to do this with an IO-area. If someone grants you the right to access port X you can't change this to port Y by specifying a receive window in you IO address space. Therefore you have to specify your whole IO address space so that IO ports are always mapped one to one. Jean -- I get up each morning, gather my wits. Pick up the paper, read the obits. if I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. Peete Seeger

2 1

Re: Question about IO-fpages
by Christian Stueble 14 Oct '99

14 Oct '99

Am Wed, 13 Oct 1999 schrieben Sie: > Hello, > > the L4 reference manual mentions IO-fpages. Has a L4 task its own > IO address space containing IO-fpages, or maps L4 the IO-fpages > into the user memory? Ok, I found the answer at the RMGR manpage :-) > It is said that always the complete IO space should be specified as > receive fpage, why? ? Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------------------------------- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Question about IO-fpages
by Christian Stueble 13 Oct '99

13 Oct '99

Hello, the L4 reference manual mentions IO-fpages. Has a L4 task its own IO address space containing IO-fpages, or maps L4 the IO-fpages into the user memory? It is said that always the complete IO space should be specified as receive fpage, why? Thanks, Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

L4 user manual
by Christian Stueble 12 Oct '99

12 Oct '99

Hallo again, I was very enjoyed to find a L4 user manual at http://www.cse.unsw.edu.au/~disy Did I look over the link at the fiasco/L4 homepage? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Driver available?
by Michael Hohmuth 12 Oct '99

12 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > Mehnert96 and Stange96 both describe an environment to use Linux-drivers > together with L3. Is something similar available to L4/Fiasco? If yes, > where can the example implementations be found? Yes, similar frameworks have been created for a number of drivers (SCSI and ATM networking drivers come to my mind). These frameworks are more of a hackish ad-hoc nature and are in no way meant as a generic device-driver framework. These drivers (and their frameworks) have not been released publicly yet, and I don't know if there are plans to release them; I guess it would be a bit embarrasing for their authors to release them because they contain a lot of write-only, proof-of-concept code written for various research projects -- code they don't want anyone to see. ;-) Maybe these authors or my boss will bite and clarify what their stance on releasing this code is. However, and probably much more interesting to you, there is now a port of Utah university's OSKit (current snapshot 990722) to the L4/x86 and Fiasco interface. The OSKit comes with a lot of Linux and FreeBSD drivers, filesystems, and a complete IP stack that, with the help of a glue library the ``port'' consists of, just run on top of L4/x86 and Fiasco. There is a piece of news at <URL:http://os.inf.tu-dresden.de/fiasco/> about the port (look for liboskit10_support). It also tells you where to download the stuff. > Does L4-Linux directly access hardware ports? Yes, the drivers contained in L4Linux directly access I/O ports. > If yes, is it possible to prevent this behavior, e.g. by inserting a > new "virtual hardware layer"? I don't understand what you mean by ``virtual hardware layer'' and what exactly you want to do, but the answer to your question probably is yes. :) Do you want L4Linux to use drivers running in separate tasks so that it becomes possible to run L4Linux without any special hardware-access privileges? Yes, that is doable. In fact, I have been dreaming about such a setup on and off; this would make it possible to run and debug L4Linux under L4Linux. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Jump to page:

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