At Wed, 23 Feb 2005 17:24:47 -0500, "Jonathan S. Shapiro" shap@eros-os.org wrote:
Some might object that the pager should not have to be trusted. What is emerging from the discussion at hand is that this architectural view does not map well to real usage. Marcus's approach of using a zero pager timeout in server->client sends implies that the client must have means to pin its receive area (a client-defined number of page frames) for an indefinite time (there may be no contract on how fast the server replies). This can induce a very real and urgent resource denial of service problem, and may be in contradiction with the residency policy requirements under which the client must operate. It works very well in non-paging environments such as embedded applications.
The reason why I hope we will get away with it is that we are pursueing a model where every task is self-paged. Tasks get a contingent of physical memory, which is guaranteed over a long time (exact details how to negotiate that number are not determined yet). There are many complications, but in the end this allows the client to make paging decisions itself, and thus it can wire down a region of memory effectively.
Sounds good, but there is a problem, and I think this just illustrates the point you were making: The physical memory server needs to be able to revoke arbitrary mappings temporarily, for example to make space for DMA buffer regions or to reorganize memory for super-page allocation. This means that the operation of the physical memory server is not transparent to the clients, and thus even to the server. (Only the kernel could make this operation transparent by an atomic copy-and-remap operation).
So, yes, the whole notion is troublesome.
Just to be clear: I'm certainly not claiming for an instant that EROS got this stuff perfect. And I think it would definitely be nice to have a paging agent that could be outside of the universally trusted computing base. Unfortunately, nobody has been able to suggest a paging architecture in which this has turned out to be feasible. In all current L4-derived systems, the region manager (or the software that plays the equivalent functional role) is necessarily trusted completely by all of the programs that it serves.
Well, we are at least trying. If it is feasible we will see when we have implemented it...
The timer event is not dropped, but instead defered - the next time the thread does an IPC, and there are no pending partners, it is canceled immediately and does not block.
It appears to me that this amounts to a special case of a more general problem: non-blocking reliable delivery of event notification. We have run into places in EROS where there is a serious need for such a mechanism, and we have been contemplating how to achieve this in Coyotos. We have now concluded that it should *not* be done in endpoints, because it is extremely desirable for endpoints to be stateless and pending events must be recorded somewhere. It is unclear at this point what alternative will emerge.
Yes. For me, such issues tend to crop up when I think about cancellation (for example due to signals). Due to lack of low-level support, we will have to do it with expensive and complicated high level constructs in the endpoints. (Now, for us this is probably OK, as we are going to need some such support anyway to correctly implement POSIX semantics. Still, it seems to be a burden and better low-level support could possibly simplify things a lot).
Thank you also for your other comments, they are very much appreciated.
Marcus