At Sat, 22 Oct 2005 03:07:16 +0200, Matthieu Lemerre <[EMAIL PROTECTED]> wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > At Fri, 21 Oct 2005 11:17:45 +0200, > > Matthieu Lemerre <[EMAIL PROTECTED]> wrote: > >> > We have established in previous emails that there tends to be a > >> > hierarchy of pagers in L4. The root of this hierarchy is privileged > >> > because it is the ultimate source of all pages. > >> > >> I don't think there is such a hierarchy in L4. > > > > [...] > > > >> What is hierarchic, though, is the mapping database of course. > > > > [...] > > > > > The mapping database is hierarchic, but it is not a concept of L4. In > > fact, the mapping database is internal to the kernel, it's not exposed > > to the user at all. > > I'd like to correct myself here: what I meant by "the mapping database > is hierarchic" was really "the tree of mappings is hierarchic". The > fact that the mapping database is the kernel structures which stores > this tree wasn't my point at all.
Ok. But the tree of mappings is actually nothing else but the abstract representation of the mapping database, so I don't see what difference it makes to the discussion. > > It can only be modified implicitely by sending map items over IPC. > > Or using unmaps with which you can delete subtrees. Right. > >> > There is no comparable hierarchy in EROS. A fault handler's job is > >> >to repair a page fault or not. Once a COPY is completed, there is no > >> >further dependency on the sender's fault handler. In EROS, the > >> >hierarchy is a matter of storage allocation, not mapping recovery. > >> > >> I really think that there is no dependency on the sender's fault > >> handler too on L4. You can have a system which never invokes your > >> pager (like the system I described in my last mails). > > > > I think there is just a misunderstanding here. The "sender of a page" > > in our Hurd-on-L4 design for example is always physmem. And any local > > page fault (which can happen because physmem is allowed to revoke > > mappings for internal reorganization) will be forwarded to physmem by > > the local pager. Thus, there is indeed a direct dependency. > > Don't worry, I know how what is implemented works. I was speaking of > the design I came up in > > http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00288.html. Oh, right, I missed that. Well, it's true that if the client maps memory to the server, then the server can not depend on it, and thus doesn't. But clearly not the whole system can work this way: At some point, some page fault handlers need to be invoked, and they need to depend on some other service to handle the page fault. Clearly, Jonathan is talking about _those_ parts of the system. That you can in addition to that provide "undependable data" to processes is "extra" and doesn't affect the argument at all. > In the current Hurd on L4, physmem has two differents semantical > roles: > > -It allocates physical memory > > -It acts as a third party for memory transmission. I agree with that. The second point is actually very big. It contains for example support for shared memory. A third role is "swap paging", btw. > Whenever a client wants to give some memory to (e.g.) a server, the > semantics of the operation is: "I want to give you memory that you can > use to serve me". The constraints on this memory gift are: > > -The gift has to be revocable (the client does not want memory to be > used against its will) > > -But this revocation must not be harmful to the receiver. If it is harmful to the receiver or not depdends on the receivers implementation. The client has no influence over this. What must be true is that the client can not break the contract. But the contract contains absolutely no requirement for the client: The client can just revoke the resource at any time. So the server must be prepared to deal with that. > >From these observations, I can thing of two classes of solutions: > > -Memory is given to and can be trusted by the receiver. This is what > the Trusted Buffer Object in EROS does, or what physmem does. > Physmem is really a trusted third-party for memory transmission. This is true or not true, depending on who you believe. I know that Neal suggested something like "pinning for short amounts of time". I believed from the start that this is bogus, and never changed my opinion, with one exception: some drivers and DMA operations, in which case "short amount of time" becomes: as long as the driver wants. > -Memory is given to the receiver, and there is no guarantee (i.e. the > "gift" can be revoked at anytime). This is what is done in general > in EROS (if the memory is revoked, the objects just disappear), and > what I think is doable on L4 e.g. for both IO and capability storage > (for instance with my proposal with the URL above, which I'm going to > complete.) This is the only workable solution, IMO. However, I think that your proposal (the link you give above) misses something important. One important operation that physmem supports is "container_copy". If the client maps the memory directly, the only way of transmission is a "paranoid_memcpy". As a consequence, sharing memory becomes impossible. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
