Re: design goals vs mechanisms (was: Re: Let's do some coding :-)

[Marcus Brinkmann]

At Fri, 28 Oct 2005 15:08:49 +0200,
Michal Suchanek <address@hidden> wrote:
> > At Wed, 26 Oct 2005 22:43:06 +0200,
> > Bas Wijnen <address@hidden> wrote:
> 
> > If you want stability, you probably want to do some of the following:
> >
> > * try formal verification
> > * allocate a fixed amount of resources statically up front,
> >   instead dynamically at run time.
> I kind of dislike this. That is one of the things that is nice in
> Hurd/Mach: you have no limit on the size of strings like filenames. I
> do not think I would like a filename that has 1M characters, but I do
> not know what is the  "reasonable limit" for filename length.

I agree with your dislike, and I am struggeling.  But there is no way
around this.  Unless you want to give the user unlimited storage and
cpu time, the story will end at the end of storage for that user.

> On the other hand, it may be possible to write servers that use bound
> amount of their own resources to serve possibly unbound requests for
> which the clients supply their resources.

Actually, this is a requirement if you want proper resource
accounting.  In fact, the server should allocate _zero_ of their own
resources to server, let's say, potentially unbound requests of a
client.

In EROS, most servers run completely on their clients resources, and
_only_ serve that client.  In this case, there is no problem.

Note that there is a slightly different problems: It is not so easy to
design robust communication channels that carry payloads with buffers
of arbitrary length.  So, there is also a practical limit.

For more information, maybe check out:

http://citeseer.ist.psu.edu/shapiro03vulnerabilities.html

> For one I do not see why such names have to be used by the system at
> all. The names can be stored as another "content fork", and files can
> be identified by some handles. Programs that show the files to users
> can then read the name in the same way they would read the data.

I think the problem here is the lookup operation.  The user doesn't
want to look up files by the handle, but by the name.

Thanks,
Marcus