>One would like to provide a mechanism whereby the memory object
>manager can provide an optional storage map to the kernel describing
>where the disk storage for the object can be found...
First, I'm not sure I understand the value of a "storage map" - is it just a performance hack to avoid having to go out of the kernel to an external pager on pagein and pageout?
Yes, but I think it's more than just a hack. There is a denial of service problem and a priority management problem concerning dirty pages that the kernel is unable to purge from memory. See the note about LRU aging that Bill Frantz mailed out earlier.
I'm actually concerned enough about this to contemplate requiring that any page the kernel cannot purge by itself come out of the object manager's pool of pinnable pages, which is likely to be small.
I did eventually find a way to manage this issue without needing a seperate map, which I will describe later. This is convenient, as the map was the only place where it looked like the kernel would want to flush object frames.
If so, I can see the potential win, but I'm not sure how big it'll be in the presence of well-optimized RPC, and in any case you could just load particular well-known, trusted pagers into the kernel for performance reasons.
The real concern is that the failure of a server (due, for example, to a wild pointer reference) can make it impossible to clean the page cache. It is desirable to minimize this problem. Also, bear in mind that if you go into things planning to double the size of the kernel, you square the number of bugs...
If [NewSys] is supposed to be a highly secure system, it still must provide a means for regulating allocation of kernel memory on behalf of clients, and presumably this would be done in much the same way as it's done in KeyKOS. Or am I missing something?
I sent out mail about this before. At the moment, I do not think that the KeyKOS model works well for NewSys.
Jonathan