Re: On PATH_MAX

[Marcus Brinkmann]

At Thu, 3 Nov 2005 12:38:19 -0700,
"Christopher Nelson" <address@hidden> wrote:
> problem.  I don't see how their relationship really matters.  Somehow A

I already tried to illustrate why.  For example, B might be a
"child-thread" of A, and thus has complete trust.  In this case, B can
do whatever A wants, and will be likely to programmed this way.

Without assuming _anything_ about their relationship, the two threads
_can_ _not_ communicate.

> has a capability that lets it talk to B.  Neither thread has any
> authority *over* each other, but B provides a service.  The problem

B provides a service under which conditions?  You have to specify.

> exists even if B provides no service to any other thread, because memory
> and processor space are shared resources.

In EROS, B has a space bank and a scheduler reserve.  This gives it
access to a certain amount of memory and cpu time.  What is the problem?

In other systems, it is similar.
  
> > > Lol. I'm not sure exactly what you're saying, but I *think* that I 
> > > agree with you. :-D  I don't so much mean that the kernel should 
> > > impose it's own idea about how much it's going to transfer, 
> > but rather 
> > > that it provide a mechanism which allows the receiver to 
> > say how much 
> > > it wants to receive.  The receiver should not be *forced* to accept 
> > > what it is given.
> > 
> > I agree with the last sentence.  But what you say before is 
> > not true in general.  The kernel must impose its own limit on 
> > a message size as well.  If you need/want to exceed that 
> > limit, then you have to implement higher-level protocols, 
> > which of course add their own problems.
> 
> The kernel may impose a limit on how much it will transfer between two
> threads in a given amount of time, but I don't see how it follows that
> it must limit how much it copies in total.

Because the operation must complete.  I think that a kernel which
provides operations that potentially don't complete has quite
unpleasant implications, for example for checkpointing.

At the very least, such a kernel can not be atomic.

I think Jonathan Shapiro did have some design to make string item
transfer lazily.  I am not sure how this design looks like, and how it
interacts with checkpointing.  But it is something that has to be
considered carefully.

> Are you saying that you wish
> the copy/map/grant operation to be an ACID operation with no state side
> effects, such that the kernel guarantees that it will copy X bytes, and
> that those bytes will either be entirely copied or not copied at all?

I think that's what I am saying, yes :)

> If so, then you cannot have arbitrary sized string transfers and still
> make that guarantee?  

I am not sure.  Is the imposed limit due to maximum memory size (which
will always be finite) enough?  In a system with a 64 bit address
space?  Mmh...  What if a process tries to send 2^64 bytes of a string
item, and in parallel another thread modifies the mapping database to
always map the same 128 MB of pages at the right moment to the right
virtual address?  Similar at the receiving side?

This would be an operation that potentially takes years.  Now, what
happens at the next checkpoint?

You have two options.  You can safe the internal state and resume the
operation at the right point after the restart.  Or you can restart
the whole IPC.  The latter choice seems to be simpler to me from the
kernel perspective.  In this case, the operation will never complete.

Ok, I think I have just shown that the kernel doesn't need to care if
it is carefully implemented.  For string items at least.  But, and
this is a big but, now you don't get any guarantee from the kernel
anymore that _any_ such IPC will _ever_ complete.  Is such an
implementation useful?  I have doubts. :)

Thanks,
Marcus