This is the effect you get from operating your own pager that you are mapping from yourself in Mach. You can layer the interface you are talking about on top of libpager. When the VM system decides to eject a page, you the pager find out and you can also have data structures mapping memory object pages to the mappings you've made, and unmap them.
Ah, yes, it would be something like convenience layer for filesystems. It is not very hard to be implemented and can be as mini-library for ext2fs, like pokel.
There are two problems to use this idea now: pager with 64-bit offsets and notification when page is evicted by the microkernel. I'll have to take a look if one struct pager can be used for multiple mappings, most probably it can.
Unfortunately, vm_map uses 32-bit offsets for defining the region that is to be mapped. This is a big stopper for 64-bit pagers. I can think of 2 solutions: vm_map64 (and all the consequences in other kernel calls), and pager_map that have to be used instead of vm_map, and that creates memory objects by demand. The second solution creates one more problem: when using libpager of another user process, memory object port is not enough anymore to map parts of this out-of-process pager. It smells like pager.defs.
Talking about libpager, I've never heard anything, positive or negative, about Neal's proposed API change[1][2].
[1] http://mail.gnu.org/archive/html/bug-hurd/2002-04/msg00110.html [2] http://mail.gnu.org/archive/html/bug-hurd/2002-04/msg00203.html
Regards -- Ognyan Kulev <[EMAIL PROTECTED],fsa-bg.org}> 7D9F 66E6 68B7 A62B 0FCF EB04 80BF 3A8C A252 9782
_______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
