Re: Fwd: Which 90% of POSIX /is/ good then?

[Brian Brunswick]

On 27/10/05, Jonathan S. Shapiro <address@hidden> wrote:
> PLEASE can we avoid the term "persistent" for this? It will be terribly
> confusing. I suggest that a better word might be "durable". What you
> seem to want is some replacement for a PID that has the property that
> (a) as long at it exists, it is bound to the same process, and (b) it
> isn't reused.

Yes, it was very bad use - sorry :-(

>
> Hmm. Sounds like a process capability!

Of course:-)

>
> Pids are also broken for another reason: they are public entries in a
> globally shared, mutable namespace.
>

Yes. I don't think there is much disagreement about these kind of
changes to POSIX.

I think the more interesting question is what to do about the
filesystem - both in terms of the global shared namespace part, and
the actual file access API.

I tend to think that exisitng practice means that trying to use
already existing filesystem subtrees for confinement isn't feasible -
it breaks too much in terms of symlinks, translators, etc.

Perhaps we need an entirely new mechanism for making limited views of
the filesystem. (when programs want access to more than just single
files.)   It would seem to need options for following/not following
symlinks, filtering on file type (no devices...).  (apache?)

This might be in the spirit of the transitively read-only type of
capability, but doing different sorts of filtering than making
read-only. It might all be done in terms of overlay/shadow mounts and
translators, I suppose. We're getting back to special sorts of jails
again.

As for the filesystem access API, I would like to see support for
significantly more transactional semantics being a natural
accompaniment to the persistence of a filesystem. Incomplete files
shouldn't be visible - simultaneous changes should be guarantee able,
Rollback of all the filesystem effects of a particular program, etc.

I think the hurd idea of translations is only a small step forward
from the traditional filesystem view, and want to go (a bit) further.

--
address@hidden