Steven Fackler

The API description in the RFC seems reasonable to me, but I don't think a full RFC is required for an addition like this - a PR direct to add...

This'll require a C shim to do portably.

Thanks for doing this! I left some comments here and there. Also, this'll need to be put behind a feature since these are Linux-only APIs I believe. I'm not totally...

Oh yeah, the options flags are definitely useful, I'd just prefer something more structured than a raw c_int. A struct with bool setters/getters seems reasonable to me.

Just so you're aware, Unix socket functionality is in the standard library now: https://doc.rust-lang.org/std/os/unix/net/

No, it means you can stop depending on this crate, and change your imports from `unix_socket::...` to `std::os::unix::net::...`.

Servo's ipc-channel uses SEQPACKET sockets which might provided some inspiration on the implementation. The API's probably going to be a bit weird due to the need to indicate packet boundaries.

Ah, I was expecting `SEQPACKET` records to be specified via `MSG_EOR` in `sendmsg` and `recvmsg` and be allowed to split across read/write calls, but they apparently behave more like connected...

I think it'd make more sense as a separate `UnixSeqpacket` struct for now, but yeah, please do!

How would it format the address? `Display` is normally only implemented for things where there's an obvious, canonical format.