i don't really think we come at it from terribly different perspectives: we both want "POSIX, the good parts," and to get rid of legacy design.
Conversation
the main difference i think is that i see POSIX as a starting point, but think that revisiting some design choices in POSIX is not a terrible thing. then again, dealing with the austin group standards process is quite tiring, so I can see why one might be hesitant
2
2
when I complain about "UNIX," I am complaining about "POSIX, as it is done *today*," not necessarily POSIX at large. basically, the question is, how do we revise POSIX to reduce legacy bloat?
1
3
for example -- the stuff Fuchsia is doing with capabilities instead of the traditional UNIX-style ACL is amazing, and we should want this to be in POSIX.
1
1
4
I've followed the whole "capabilities" thing for decades and never found any value in it besides "lets just pretend we're not root despite having complex interacting powers that are hard to reason about and almost always root-equivalent".
2
1
1
It's not at all the same kind of thing as *nix capabilities but rather FreeBSD Capsicum. It's an object capability system for associating rights with objects. It's not something bolted on to an existing system but rather what it's based around in the first place though.
1
1
6
fuchsia.dev/fuchsia-src/co is a nice overview of how file access works, which is just one example of a FIDL protocol implemented on top of object handles.
Namespaces are an inherent part of the basic way of using it. You simply make a little filesystem object out of other objects.
2
3
I skimmed through that and I love how they have some of the basic concepts from my vaporware kernel (fs being provided by a userspace process, only visible to procs attached to it) but then botched a lot to make that happen s.t. mmap is read-only. 🤦🤦🤦
3
...and demand paging doesn't exist. 🤦 ...and you have to use mmap rather than read for performance. 🤦 This all comes out naturally right if the only underlying operation is mmap-like and read/write are always kernel-mediated memcpys.
2
1
1
The kernel portion of it is supported and it's supported by BlobFS which is most of the OS other than persistent state. The documentation seems out-of-date.
fuchsia.dev/fuchsia-src/re
Most of the infrastructure for supporting writes is there but the filesystems don't do it yet.
My point was more that the basic architecture/interface between kernel and fs-provider if wrong if this doesn't just work by default.
1
I think the reason that it's not implemented is simply that only BlobFS implements demand paging so far and BlobFS is write-once content addressable. I don't think there's any design issue or blocker for it. They just haven't gotten around to implementing it for a normal fs yet.
1
2
Show replies