[prev in list] [next in list] [prev in thread] [next in thread]
List: eros-arch
Subject: [EROS-Arch] Extended node fetch/swap
From: "Jonathan S. Shapiro" <shap () eros-os ! org>
Date: 2001-09-23 19:16:51
[Download RAW message or body]
I want to propose that we add an operation to the node key that walks a node tree \
using the same algorithm as the current segment tree walker. The operation is:
extended_fetch(node, address) => key
extended_swap(node, address, key) => old_key
This should follow precisely the same LSS and windowing conventions as normal address \
spaces. In fact, it should be implemented by the same walker code and should \
implement the same access restrictions.
The walker will proceed through the node tree until it reaches a node whose LSS is \
PAGE_LSS. It will assume that this is a leaf node in the tree, and that the desired \
destination capability resides at some slot within this node.
Note that this termination condition has a slightly different logic from the one used \
for address spaces. In an address space, you could place an arbitrary further chain \
of nodes between the PAGE_LSS+1 node and the final page key, provided that all of \
those nodes had LSS > PAGE_LSS. The problem with following this logic in the extended \
fetch/store traversal is that if we follow the page translation rules exactly it \
would be impossible to store node keys at the leaves.
Credit where it is due: I believe that Charlie Landau proposed exactly this in a \
previous message at one point.
Jonathan
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4807.2300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>I want to propose that we add an operation to the
node key that walks a node tree using the same algorithm as the current segment
tree walker. The operation is:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> extended_fetch(node, address)
=> key</FONT></DIV>
<DIV><FONT face=Arial size=2> extended_swap(node, address,
key) => old_key</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>This should follow precisely the same LSS and
windowing conventions as normal address spaces. In fact, it should be
implemented by the same walker code and should implement the same access
restrictions.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The walker will proceed through the node tree until
it reaches a node whose LSS is PAGE_LSS. It will assume that this is a leaf node
in the tree, and that the desired destination capability resides at some slot
within this node.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Note that this termination condition has a slightly
different logic from the one used for address spaces. In an address space, you
could place an arbitrary further chain of nodes between the PAGE_LSS+1 node and
the final page key, provided that all of those nodes had LSS > PAGE_LSS. The
problem with following this logic in the extended fetch/store traversal is that
if we follow the page translation rules exactly it would be impossible to store
node keys at the leaves.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Credit where it is due: I believe that Charlie
Landau proposed exactly this in a previous message at one point.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Jonathan</FONT></DIV></BODY></HTML>
_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic