[Xen-changelog] [xen-unstable] docs: update some todo items.

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User kfraser@xxxxxxxxxxxxxxxxxxxxx
# Date 1173779531 0
# Node ID f2f83691f7148b9780f8e6e4dd0475970a3645cf
# Parent  468ec3d142add32033169b703501116b3bdb7590
docs: update some todo items.

Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
---
 docs/xen-api/todo.tex |   11 ++---------
 1 files changed, 2 insertions(+), 9 deletions(-)

diff -r 468ec3d142ad -r f2f83691f714 docs/xen-api/todo.tex
--- a/docs/xen-api/todo.tex     Tue Mar 13 09:07:55 2007 +0000
+++ b/docs/xen-api/todo.tex     Tue Mar 13 09:52:11 2007 +0000
@@ -91,17 +91,10 @@ same subnet.
 
 \end{itemize}
 
-\item TPM
+\item ACM
 \begin{itemize}
 
-\item Would it not be better to have a class TPM and a member TPMs ((TPM ref)
-Set) containing an array of zero or one references to TPMs? I assume that
-an empty array would make it clear that no TPM is associated with the VM
-instead of encoding its existence into TPM/instance or TPM/backend
-somehow. The current members instance and backend could then be moved into
-the TPM class.
-
-\item Also a Xen system can be running an access control policy where each
+\item A Xen system can be running an access control policy where each
 VM's run-time access to resources is restricted by the label it has been given
 compared to those of the resources. Currently a VM's configuration file may
 contain a line like access\_control[policy='$<$name of the system's

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog