1. 27
  1. 8

    Hey I work on that.

    1. 2

      One thing I’m curious about is the handling of endianness. The wire format docs say that FIDL is little-endian only, but the IPC protocols I’m used to (D-Bus, FUSE) are either native-endian or have a header flag.

      Furthermore, the decoding step describes how to transform some content (pointers, handles) but nothing about swapping endianness of integers, which makes me think that the in-memory representation of a “decoded” message would also be little-endian in all cases (i.e. it’s not just a matter of encoded bytes “on the wire”).

      Is this correct? If so, it seems strange given that it completely locks out big-endian platforms like s390 or Power.

      The reason I ask is that FIDL seems like a good foundation for a general-purpose IPC protocol (similar to gRPC’s role for RPC). I have some vague interest in exploring it as a replacement for the FUSE protocol, but the endianness limitation would prevent it from ever being accepted into a mainstream kernel such as Linux or FreeBSD.

      1. 4

        FIDL was initially defined as being native endian but it’s only used on little endian machines and we don’t have any practical ability to put it on big endian machines for testing. In practice the implementations of FIDL probably only work correctly on little endian machines. This meant that our implementations were probably violating the spec but we lacked any way to test this or fix it. The answer was to tighten the spec to what we have the ability to test. This change was written up: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0030_fidl_is_little_endian

        The endianness bugs are almost certainly simple and would be caught by our extensive encoding test suites, if they could run on big endian machines. I imagine the spec could be relaxed if it became practical to make the assertion with a straight face.

    2. 2

      Back when I was working on fuchsia (to be very clear: I was not a significant contributor to it), FIDL was one of those concepts that I really wish could be adopted for more systems, but of course existing systems are somewhat stuck because everything is misery once you have existing software.

      That said better support for structured cross process messaging would be nice - Mac/iOS has XPC but it’s fairly heavy for small amounts of non-object data, and kind of annoying to use, and prone to security problems (object serialization continues to be hard)

      1. 2

        Darwin has always had lower-level Mach messaging, which has its own IDL (MIG). I used a little back in 2006 or so; it worked well, it was just poorly documented. It seemed like Apple didn’t expect developers to use it (this was before XPC, but you could use DistributedObjects over a local pipe.)

        One of the cool things about Mach messaging is that it’s capability-based. Mach ports (i.e. stream handles) can be passed through an IPC call, making them secure capabilities.

        1. 3

          FIDL is similarly capability based. Communication happens over channel handles and handles can be passed in messages.

          1. 3

            I always forget MIG. I feel like the core problem with MIG wasn’t the concept, but rather the API. The object ownership semantics were non-trivial and have been the cause of many security bugs over the years.