Rethinking fsinfo()

When decoding strings or byte arrays, it can read directly from the stream into the decoded message struct (if the field is configured with a fixed max size) or into a malloced buffer (if configured with variable size) or can pass a substream object representing the value into a callback function. Using the callback interface would let the kernel copy directly from the userspace input buffer into the appropriate internal kernel struct.

It looks like FlatBuffers can't do that, because verification (to avoid out-of-bounds reads etc) is a separate operation from reading fields. You'd have to memcpy the whole buffer from userspace to kernel memory before verifying and then copying strings again into kernel structs.

For kernel-to-userspace messages, you don't need to worry about race conditions and you probably don't need the verification step (since you have to trust the kernel anyway), so FlatBuffers could work better there.

For userspace-to-kernel in both protocols, if you really don't want to force the user to pack all their data into a single buffer, you could always encode userspace pointers as integers (like a "fixed64" in protobuf) to point to raw data or encoded messages at other addresses, and the kernel can traverse those pointers manually like it does today. You'd still get the benefit of automatic marshalling for the majority of structs and fields.