On 27/10/05, Jonathan S. Shapiro <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
