l4-hackers

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

2827 discussions

Re: L4 Mapping question
by Michael Hohmuth 23 Feb '99

23 Feb '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > A related question here. Is there any particular reason/need for > sigma zero to be a once off pager? Why not have an inteligent resource > manager for sigma zero? In L4/x86 and Fiasco, this is easily possible. Sigma0 runs on user level and can be substituted at boot time with any program you like. The resource manager Rmgr (which is normally used to startup L4/x86 and Fiasco) handles the nitty-gritty details of telling the kernel where it should find its Sigma0 server. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

INCREASE YOUR PROFITS INSTANTLY!
by Shawn 23 Feb '99

23 Feb '99

***INCREASE YOUR PROFITS*** ACCEPT CREDIT CARDS FOR YOUR BUSINESS AND INCREASE YOUR PROFITS 30%-50%! *INTERNET *STOREFRONT *HOMEBASED OR *MAIL ORDER BUSINESS WE SPECIALIZE IN HELPING THE SMALL BUSINESS OWNER! IF YOU CALL IN THE NEXT FIVE DAYS, YOU WILL RECEIVE: NO APPLICATION FEE NO PROGRAMMING FEE CALL 1-888-264-9272 OUR BUSINESS HOURS ARE 9:00 A.M. TO 6:00 P.M. MST Remove at: mailto:mcau@hotbot.com?subject=remove

1 0

RE: L4 Mapping question
by vuhlig＠us.ibm.com 22 Feb '99

22 Feb '99

Hi Robert, the 5 mappings are on average (and configurable!). They are not assigned to one particular frame. I used the term frame in the context of available physical memory. you need some additional mapping entries for devices (like video frame buffer). The kernel must keep track of the mappings, because otherwise the pager can not revoke a page from an address space, where the page was indirectly mapped to. (e.g. A=pager mapps to B and maps to C, D, and E. Hereby, A is only aware of the mapping to B.) But the kernel concept allows to map any available/mapped memory from one address space to another. Volkmar Robert Kaiser <rob(a)sysgo.de> on 02/22/99 11:43:16 AM Please respond to Robert Kaiser <rob(a)sysgo.de> To: Volkmar Uhlig/Watson/IBM cc: Subject: RE: L4 Mapping question Hi Volkmar Thanks again for your response! On Mon, 22 Feb 1999 vuhlig(a)us.ibm.com wrote: > there is one mapping entry per associated page per address space. that > means, if you map a page to 2 address spaces you need 2 mappings. The > current L4 version allocates the mappings statically (currently 5 entries > per frame, but this is configurable at startup time). I seem to have a little difficulty with the term "frame". It may have to do with the fact that I don't have much of an Intel background (I'm developing mostly for MIPS machines). Does it mean something like "physical page" ? If so, that would mean that there is a hard (though configurable) limit of five address spaces that can share any given page. Is that correct ? > The idea is, that the kernel can revoke pages from sigma 0, what is not > implemented yet. I don't see the case, where you want to map a lot of pages > into all address spaces. The case I had in mind is shared memory between user tasks running on top of a -say- L4Linux server (and possibly being unaware that they are in a microkernel environment). I would not like the microkernel to impose a limit on the number of tasks that can share a given piece of memory. > Furthermore is your calculation not right. You can > map a page to multiple address spaces multiple times (at different virtual > addresses) - so there is no limit of needed mapping-entries per page. Oops, I hadn't thought of that! Would it be such a bad idea to move the bookkeeping for fpage_unmap out of the microkernel altogether? I mean, the pager has to do some bookkeeping anyway (like Sigma0 marks all pages once it maps them so it can refuse multiple mapping attempts). So, if the fpage_unmap syscall would just unmap a given fpage for a *single*, given address space and the pager would be responsible for making one fpage_unmap call for each task it has previously mapped the fpage to, then all bookkeeping would be in one place (i.e. the pager). This would simplify the microkernel, reduce it's memory footprint and leave the implementation details up to the user-space pager, which seems to me like the "microkernel way" of doing things. Of course, this would result in more system calls being made (thus more overhead), but I guess that in the usual cases (such as up to five tasks sharing a page) this should be negligible. I suppose there must be some other good reason why it wasn't done this way... Thanks again Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80 D-55129 Mainz / Germany fax: (49) 6131 9138-10

2 1

RE: L4 Mapping question
by vuhlig＠us.ibm.com 22 Feb '99

22 Feb '99

Hi Robert, there is one mapping entry per associated page per address space. that means, if you map a page to 2 address spaces you need 2 mappings. The current L4 version allocates the mappings statically (currently 5 entries per frame, but this is configurable at startup time). The idea is, that the kernel can revoke pages from sigma 0, what is not implemented yet. I don't see the case, where you want to map a lot of pages into all address spaces. Furthermore is your calculation not right. You can map a page to multiple address spaces multiple times (at different virtual addresses) - so there is no limit of needed mapping-entries per page. Volkmar

1 0

RE: L4 Mapping question
by Robert Kaiser 22 Feb '99

22 Feb '99

Volkmar, Thanks very much for your response ! On Mon, 22 Feb 1999, Volkmar Uhlig wrote: > The bookkeeping is done by the kernel. this is necessary, because the > sender (e.g. pager) does not know, if the receiver of the page maps it to > other address spaces. Therefore the flush operation must be asynchronus. > Example: A is pager and maps a page to B. B maps it to C, D, E, and F. if A > flushes the page, it is removed from B, C, D, E and F. So, multiple mappings are in fact possible (that's what I wanted to know). I was aware that the bookkeeping would have to be in the kernel, otherwise flush couldn't work as described in the manual. Only, how does it work ? Theoretically, each task could map each of it's pages to up to 2047 other tasks. So, the kernel would need to maintain ~2K entries per mapped page and task. This can't be! The only explanation I can think of right now is that the kernel allocates room for entries dynamically, assuming that the actual number of required entries will always be far less than the theoretical limit. But that would mean you can break the system simply by doing a big enough number of mappings. > In the current L4-implementation of Jochen Liedtke, one mapping entry is 16 > Bytes.The Alpha implementation (done by me) needs 32 Bytes per entry (64 > bit address space - and a lot of trix). The Fiasco kernel does not use > lists. They need about 4 Bytes per entry + an some overhead per frame (I > left bevore it was finished) > I am getting the distinct feeling that I am missing something very simple :-(. So, at the risk of looking like a complete fool: How do you keep track of up to 2K tasks in a 16 Byte entry ? Thanks for your response Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80 D-55129 Mainz / Germany fax: (49) 6131 9138-10

1 0

Re: Deceiving IPC question: Bug or Feature?
by Michael Hohmuth 03 Feb '99

03 Feb '99

gernot(a)cse.unsw.edu.au writes: > We have noticed the following re deceiving IPC in L4/MIPS. > > Assume task A is the chief of task B, which is the chief of task C. aa > is a thread in A, bb a thread in B, cc a thread in C. > > aa does a closed receive from bb. bb sends a deceiving message to aa > with cc as the virtual sender. aa receives the message (although the > virtual sender is different from the source specified in the > receive). The kernel returns to aa the virtual sender specified by bb > (i.e., cc), but the C bindings discard this information, so aa cannot > see it using the C interface. > > If in the otherwise identical situation aa does a closed receive from cc > it does NOT receive the message. > - is this the correct behaviour? I think this should be reversed: aa should receive the message in the second scenario, but not in the first. > - do all L4 versions show this behaviour? We never really used deceiving IPC with L4/x86 version 2 because it was broken, and I don't know about Jochen's version 3 or L4/Alpha. In Fiasco, deceiving IPC hasn't been implemented yet; it's not a priority for us right now. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Deceiving IPC question: Bug or Feature?
by gernot＠cse.unsw.edu.au 02 Feb '99

02 Feb '99

We have noticed the following re deceiving IPC in L4/MIPS. Assume task A is the chief of task B, which is the chief of task C. aa is a thread in A, bb a thread in B, cc a thread in C. aa does a closed receive from bb. bb sends a deceiving message to aa with cc as the virtual sender. aa receives the message (although the virtual sender is different from the source specified in the receive). The kernel returns to aa the virtual sender specified by bb (i.e., cc), but the C bindings discard this information, so aa cannot see it using the C interface. If in the otherwise identical situation aa does a closed receive from cc it does NOT receive the message. My questions: - do all L4 versions show this behaviour? - is this the correct behaviour? Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser(a)unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint = 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F

1 0

Re: Aiee: scheduling in interrupt (PR#9)
by Michael Hohmuth 29 Jan '99

29 Jan '99

> From: roux(a)ecoledoc.lip6.fr (Cedric ROUX) > Subject: some bugs > To: l4-hackers(a)os.inf.tu-dresden.de > Date: Fri, 11 Dec 1998 13:23:47 +0100 (MET) > > [...] > i could run koules with svgalib !! but, a program of mine don't > work. If someone could try it to see if it's my machine or what ? > available at : > http://www.ecoledoc.lip6.fr/~roux/demo/lost.tar.gz > and a binary is provided at : > http://www.ecoledoc.lip6.fr/~roux/demo/lost > If you could try it with a clean linux to see what should be > the correct behavior, then try it with fiasco. > It's just a poor animation with some sound (maybe sound is necessary for it > to behave bad, don't know). > When i run it under fiasco, it runs a little, then it blocks, so i press > ctrl+c, that nornmally should end up the program and give me back the > shell, but not, it just continues a little more, and stops again, and so on > until the end of the program. > Then i see a lot of "Aiee: scheduling in interrupt 00422ba (activ 10000)" > with sometimes a 0 in place of the 10000. > This works too with patch3, i don't have put patch4, but don't think > it is relevent. > And when i press Esc, it simply reboots. > > [...] What kind of sound driver did you use with L4Linux? Did you compile it into the L4Linux server, or did you use some kind of module? Please note that normal kernel modules for monolithic Linux cannot be used with L4Linux. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

RE: Aiee: scheduling in interrupt (PR#9)
by Sebastian Schoenberg 29 Jan '99

29 Jan '99

That means, you cannot take your binary compiled for your standard Linux, but you can take the source code without any changes and compile it for the L4Linux architecture. Sebastian -----Original Message----- From: Michael Hohmuth [SMTP:fiasco-bugs@os.inf.tu-dresden.de] Sent: Friday, January 29, 1999 4:41 PM To: roux(a)ecoledoc.lip6.fr Cc: l4-hackers(a)os.inf.tu-dresden.de Subject: Re: Aiee: scheduling in interrupt (PR#9) What kind of sound driver did you use with L4Linux? Did you compile it into the L4Linux server, or did you use some kind of module? Please note that normal kernel modules for monolithic Linux cannot be used with L4Linux. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Cash in on Superbowl Sunday!!
by z78c＠hotmail.com 29 Jan '99

29 Jan '99

Superbowl XXXIII - JANUARY 31, 1999 Dear Sports Fan, WIN BIG gives you the opportunity to make the game more exiting and profitable, with our online sportsbook. You can make a friendly wager on the SUPERBOWL or any other pro sporting event. Or play our many interactive casino games that come with our free sopftware package. Visa Mastercard and American Express accepted and for a limited time we are offering a complimentary 10% of your initial deposit added to your account upon sign-up ! Please visit our website for more info: http://204.71.176.71/members6/game-online Please contact interrupt(a)hotmail.com if you have recieved this message in error. Thank you, and happy gaming!

1 0

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