l4-hackers February 1999

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

10 participants
14 discussions

ADV: New Daul Mount Copy Holder
by remove＠1vm.com 24 Feb '99

24 Feb '99

Amazing new copy holder can be mounted directly on your computer monitor or it can be used freestanding. Unique design is specifically engineered to increase your efficiency while reducing eye strain, stress, and fatigue. Quality Rubbermaid features include adjustable viewing positions, non-glare surface, spring load paper clamp and detachable line guide. Folds flat for easy out-of-the-way storage. This isn't a cheap clip on, but a full platform copy holder. Special internet savings click … [View More]

1 0

Big break!
by Ronald 24 Feb '99

24 Feb '99

Start your own 1-900 business! People are making $$$ week, after week in the 1-900 business. We'll teach you all of our "incredible secrets that will take your new exciting business to a whole new level! It's The Simplest and Most Exciting Business You Could Ever Start! *You'll use our "state" of the art equipment! *You'll use our "Live 1 on 1 Psychics" & "Chat Line" girls! *You'll use our incredible Date Line program(s)! No chargbacks! Quick payouts! No expertise needed! Complete … [View More]

1 0

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

23 Feb '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > What TID does the kernel use for its ipc to Sigma0 to request > memory mapping for kernel usage. L4/x86 uses task 1, local thread 0, for communication with Sigma0. The Fiasco kernel doesn't do any IPC operations on behalf of itself -- so no thread id here. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

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

23 Feb '99

Robert Kaiser <rob(a)sysgo.de> writes: > 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 … [View More]

1 0

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

23 Feb '99

vuhlig(a)us.ibm.com writes: > The idea is, that the kernel can revoke pages from sigma 0, what is not > implemented yet. [...] I don't think it is a part of the Sigma0 specification that Sigma0 should be able to handle the case where the kernel revokes mappings of pages mapped into Sigma0. Instead, Sigma0 is pretty safe to assume that it magically owns---and has access to---all physically- addressable memory (maybe with the exception of the kernel-private code and data sections; the … [View More]

2 1

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

23 Feb '99

I wrote: > 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. In order to avoid any confusion: In a typical booting scenario on the x86, the Rmgr bootstrappig code runs even before the L4 or Fiasco kernel has been started. It is invoked directly by the boot loader and handles all initializations to be done before the kernel starts up: It finds the raw ELF … [View More]

1 0

L4 Mapping question
by Robert Kaiser 23 Feb '99

23 Feb '99

Hi all, I have a question regarding mapping in L4: I read in the L4 reference manual that Sigma0 maps each page only once. It does allow multiple mappings of a page to the same address space (i.e. task), but it does not allow multiple mappings to different tasks. Is this a specific feature of Sigma0 or is this true of all pagers ? I'm asking because I wonder how the fpage_unmap operation works: If a task is allowed to map a page to an unlimited number of different tasks (i.e. 2047 as there … [View More]

3 3

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 … [View More]

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: … [View More]

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 … [View More]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 [View Less]

2 1

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 February 1999