l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sawmill's dataspaces and the Hurd's physmem


From: Ronald Aigner
Subject: Re: Sawmill's dataspaces and the Hurd's physmem
Date: Mon, 05 Sep 2005 11:15:46 +0200
User-agent: Debian Thunderbird 1.0.2 (X11/20050817)

Hi,

Neal H. Walfield wrote on 09/04/2005 09:45 PM this:
<snip>
> In the Sawmill dataspace model [1], the file system server is a
> dataspace manager which likely provides a dataspace for each file.
> When a task wants to use a file, it first identifies the dataspace
> associated with the file (e.g. gets a capability to the file from the
> DM) and attaches it to its address space (e.g. tells its pager to
> associate a portion of the VM with the capability).  "After an attach,
> the region mapping forwards all page fault requests in that region to
> the dataspace manager.  The dataspace manager resolves the faults with
> map or grant operations."
>
> I understand this to mean that a client depends on a DM to:
>
>  - provide mappings to data
>  - provide resources backing the data
>
> When a client requests some data from a dataspace, the DM provides a
> mapping to the client.  The client can proceed to use the data,
> however, at any point, the server could cause the mapping to be
> unmapped and possibly render the data inaccessible.  The implication
> is that the client must either trust the server to always provide the
> mapping or be prepared to recover should the data disappear.  The
> latter approach can be simplified by making a physical copy of data
> before committing to using it (which can be done by interposing a
> second DM between the DM and the client).  General use of this tactic
> means a lot of cycles will be spent copying bytes and a reduction in
> the amount of physical memory sharing in the system.
<snip>

It appears to me that a file system server providing a file to a client
always belongs to that client's trusted computing base. The FS server
has to belong to the client's TCB, because it will provide the client
with the content of a file. It may alter that content in any possible
way before handing it to the client.

Given that trust relationship, the revocation of pages may or may not be
part of the protocol the client and the server agreed upon. If no pages
shall be revoked, the client *knows* that the server will not revoke
pages, because the client trusts the server.

Therefore, the FS server can be the DM for the file, the client
requested: No need to drop that approach.

If my assumption is false, then your argumentation seems feasable.

Greetings, Ron.
-- 
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]