Re: [COFF] Other OSes?

On Sun, 08 Jul 2018 22:44:23 -0400 Dan Cross <crossd(a)gmail.com> wrote: Dan Cross writes: I tend to think they are orthogonal. Namspaces map names to objects -- they control what objects you can see. Capabilities control what you can do with such an object. Cap operations such as revoke, grant, attenunating rights (subsetting the allowed ops) don't translate to namespaces. A cap is much like a file descriptor but it doesn't have to be limited to just open files or directories. As an example, a client make invoke "read(fd, buffer, count)" or "write(fd, buffer, count)". This call may be serviced by a remote file server. Here "buffer" would be a cap on a memory range within the client process -- we don't want the server to have any more access to client's memory. When the fileserver is ready to read or write, it has to securely arrange data transfer to/from this memory range[1]. You can even think of a cap as a "promise" -- you can perform certain operations in future as opposed to right now. [Rather than read from memory and send the data along with the write() call, the server can use the buffer cap in future. The file server in turn can pass on the buffer cap to a storage server, there by reducing latency and saving a copy or two] The point of my original comment was that if capabilities were integral to a system (as opposed to being an add-on like Capsicum) a much simpler Unix might've emerged. [1] In the old days we used copyin/copyout for this sort of data transfer between a user process address space and the kernel. This is analogous.