3 ms·

I'm quite surprised a new API like this got merged without a clear (public) indication for why it was needed. Given that Linux commits to never breaking user-sp

I'm quite surprised a new API like this got merged without a clear (public) indication for why it was needed. Given that Linux commits to never breaking user-space, I'd imagine adding this new feature incurs a substantial and near-permanent cost in terms of maintenance, security, etc. Is the mental model for this to treat it like a device driver (where it's off by default and can be turned on under specific circumstances), or is this thought of as part of the default-available kernel API that every system will have access to from now on? (I guess FUSE itself is a little fuzzy in this respect)

xani_ 4y ago
I'm not. It's a wet dream for any company that wants to do distributed block storage but doesn't want to update kernel module every time the new feature or fix gets added; nowadays a lot of that (like Ceph's RBD driver) needs to be in kernel, and it would need to be backported any time new feature that client wants would come along. The code is tiny compared to full implementation of any of the block drivers and allows them to be moved to userspace so it also potentially saves a lot of maintenance in the future, because it would be the first choice if you're implementing another distributed block file system. > Is the mental model for this to treat it like a device driver (where it's off by default and can be turned on under specific circumstances), or is this thought of as part of the default-available kernel API that every system will have access to from now on? (I guess FUSE itself is a little fuzzy in this respect) As a device driver that can be fully tested with no actual hardware, and much smaller area of attack than real driver.