RE: On PATH_MAX

[Christopher Nelson]

> > On Tue, Nov 08, 2005 at 08:51:09AM -0700, Christopher Nelson wrote:
> > > > Not exactly.  If a server wants to support arbitrary 
> long paths, 
> > > > it's not going to map the whole thing into its address
> > space.  It'll
> > > > accept a container capability and map parts of it in, unmapping 
> > > > other parts of it.
> > > 
> > > 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.

Besides which, how is that functionally different from having a bounded
string copy with a more sophisticated protocol that transfers one
portion at a time?  I don't think that putting that complexity into
kernel state is a good idea.  IMHO.

-={C}=-