> In principle, we need to do this already! The glaringest security
> issue with the Hurd right now is the assumption that all users will
> just take their pagers and hand them to the kernel with vm_map. But
> they might play as "kernels" themselves. To deal with this, the
> pagers need to be able to deal with multiple "kernels", and also have
> strategies for dealing with recalcitrant "kernels" that aren't
> behaving properly.
Wow! I had not thought of that. Thanks.
> > From what I can see, the pager_memcpy function can be extremely slow.
> > Just consider what happens when we just want to replace a page on disk
> > (which has not yet been read in to memory). pager_memcpy causes a
> > page fault. The kernel sends a message to the manager which reads the
> > page from disk (which is completely unnecessary), then, we write to
> > the page and eventually, it is flushed back to the disk. This is even
> > worse if we are writing to multiple pages -- our thread and the
> > manager thread play ping-pong! This could be avoided by acquiring as
> > much of the range up front as possible.
>
> Why do you think this is so horrible? This is just demand paging.
In the scenario case, we do a completely unnecessary read! That is
not demand paging; that is a waste.
> What's supposed to be going on behind the scenes is that the kernel
> should detect that you are faulting the pages in sequentially, and ask
> for pages from the pager ahead of time, optimizing the sequential
> access case.
But the manager knows; why force the kernel to guess? Say we send:
io_read (file, data, vm_page_size * 4, 0, &amount)
By the time the kernel detects a sequential read, it is already too
late to be of any use.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
