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.
Conversation
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.
1
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
I doubt they plan on keeping their existing traditional fs:
fuchsia.dev/fuchsia-src/co
It looks like their focus is almost entirely on BlobFS. I don't think they have something particularly new to bring to the table for traditional filesystems and the focus is breaking new ground.
2
1
Yeah as usual their focus is "move fast and break things"...
1
1
I think they're working on implementing F2FS but it's a lot of work especially for it to be fully compatible.
It doesn't help that Linux F2FS is in very active development and regularly upgrading the on-disk format. You can't downgrade the major kernel version with F2FS yet...
1
1
F2FS has really great performance and reliability but it's only currently a serious choice where you're heavily testing major kernel upgrades in advance and are completely sure you won't need to downgrade. I'm sure that hurts the development-focused Fuchsia use case right now.
I still use ext4 on my workstations in case I ever need to downgrade the kernel, especially since I use a rolling release distribution. OS development with that constraint is probably not fun. I broke that rule before and had to reformat since F2FS became unable to reuse space.
1
F2FS checkpoint=disable is neat. Android uses it for mounting data when booting after an OS upgrade. New OS version can migrate databases to new formats, etc. It waits until the last moment when the lock screen loads to enable checkpointing. Nothing gets committed until then.