RE: On PATH_MAX

[Christopher Nelson]

> 
> 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}=-