>
> On Tue, Nov 08, 2005 at 10:04:50AM -0700, Christopher Nelson wrote:
> > > > What mechanism allows it to map *parts* of a single transfer in?
> > >
> > > There is no transfer of data, there is only transfer of the
> > > container capability. This capability gives access to a set of
> > > pages, which can be mapped in or out of the address space
> when the
> > > process likes.
> >
> > You still have data transfer, even if it's only in the form
> of metadata.
> > A thread can't access any memory until it's mapped into its address
> > space. If you say that a thread must only keep a handle to the
> > metadata that defines the memory and then map it in and out
> as needed,
> > you essentially turn the operation into an
> open..read..close, and you
> > add tremendous complexity in the form of a buffering layer to map
> > pages in and out. I'm not saying its impossible, I'm
> saying its not a
> > good idea, IMHO.
>
> Of course _if_ it's done, then it should only be done for
> long transfers.
> That is, if the majority of transfers will be short (say less
> than the page size), then direct transfers should be
> accepted. But there must be a limit to their size.
This is exactly what I have been saying. Thank you.
> Larger
> objects can be transferred using containers. It is no
> problem if there is lower performance in that case, as long
> as it doesn't hurt the normal (little data) case. I didn't
> think it through well enough to see if it would, but I think
> the cost would not be much. However, the complexity alone
> may be a reason not to want it. However, removing arbitrary
> limits is a good idea in general IMO.
Sure, but that complexity should be in the application code and
protocol. Not in the kernel. IMHO.
-={C}=-
_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd
