The biggest problem with caps and legacy apps is not the semantics - a caps systems can emulate POSIX with no problem. The problem is the data representation: you can't fit a capability into a pointer, so all the data layouts change. Sadly, there are tons of C programs that make rash assumptions about data layout, and they would all break.
The guys are Cambridge have running caps systems that store the extra info in outboard data structures. We judge that the overhead is too great for commercial success. Customers buy benchmarks, and there are no security benchmarks.
'Tis true 'tis, 'tis pity. 'Tis pity 'tis, 'tis true.
Re:Mill CPU Inter-Process Communication
by deepnotderp on Monday October 09, 2017 @12:56AM
(#15431663)
> i still dont understand how local/global exactly matches the semantics of cow.
It's not, it's "copy on reference".
No, it's aliasing, just as any fork() is. COW lowers the cost, for Mill as for any other. The Mill fork duplicates the address space, not the memory. The memory is duplicated page by page on demand, i.e. copy-on-write. Mill paging is quite conventional; it's the address space (SAS) that is different.
Re:Mill CPU Inter-Process Communication
by cwzwarich on Monday October 09, 2017 @01:07AM
(#15431698)
They were light on the details, but what stops an OS from mapping the same physical page into two distinct local regions of the address space and implementing copy-on-write as usual?
Re:Mill CPU Inter-Process Communication
by deepnotderp on Monday October 09, 2017 @01:50AM
(#15431805)
Presumably nothing, but it doesn't seem like that would break anything?
transitive permissions are capabilities.
while i'm sympathetic to the lack of market appeal to a capability based system, doesn't it seem like you could implement posix on top of one by compromising it? fd transfer over unix domain is already halfway there.
seems like a better alternative.