net/uds: add methods to connect/bind with a socket address

[lucab]

This enhances connect and bind logic for Unix Domain Sockets (UDS), by adding methods which allow to directly use a socket address. This mirrors similar features which already exist in mio for TCP and UDP sockets.

[Thomasdezeeuw]

I assume this is based on rust-lang/rust#85410, which seems to be on it's way to stable.

[lucab]

@Thomasdezeeuw yes, kinda. My final goal would be to use abstract UDS in tokio (and higher up). For that I'm really looking forward to SocketAddr::from_abstract_namespace(&[u8]), which is still currently moving a bit. So maybe later, I'm not in a hurry.

I started with this which only tackles the connect/bind side, as it seemed quite safe to do and I noticed that TCP/UDP already had them.

[Thomasdezeeuw]

@Thomasdezeeuw yes, kinda. My final goal would be to use abstract UDS in tokio (and higher up). For that I'm really looking forward to SocketAddr::from_abstract_namespace(&[u8]), which is still currently moving a bit. So maybe later, I'm not in a hurry.

I think you can use socket2 in Tokio, that already support abstract namespaces.

I started with this which only tackles the connect/bind side, as it seemed quite safe to do and I noticed that TCP/UDP already had them.

[lucab]

The CI here is running clippy linting without a pinned version of the toolchain, which means new warnings appearing in newer toolchain versions will silently break master and block unrelated PRs.

I did add a commit on top here to fix the new clippy warnings, but you may consider pinning the linting toolchain too.

[Thomasdezeeuw]

The CI here is running clippy linting without a pinned version of the toolchain, which means new warnings appearing in newer toolchain versions will silently break master and block unrelated PRs.

It's really breaking anything, it's just pointing out areas of (possible) improvement.

I did add a commit on top here to fix the new clippy warnings

👍

but you may consider pinning the linting toolchain too.

We only pin the MSRV, not the maximum.

[lucab]

Just asking explicitly, what are the next steps here? Is this additional API fine here in mio or was the comment above suggesting to directly put this in tokio instead?

[Thomasdezeeuw]

Just asking explicitly, what are the next steps here? Is this additional API fine here in mio

Yes.

or was the comment above suggesting to directly put this in tokio instead?

Yes. :)

Basically, Mio follows the std lib, so I think we should wait until the API at least on the road of stabilisation in std lib. Then we match the api and aren't stuck with a different API due to a last minute name change in std lib, after we already made a release with the function.

So, if you want in Tokio today your best bet is to use socket2 directly their. But I don't decide what does and doesn't go in the Tokio api.

[lucab]

Ack, thanks for the feedback. I'll leave this open here for the moment then, and revisit once stdlib stabilization is done.

I'll go check Tokio next, and see if they like a socket2 implementation there. I can then hopefully switch that to use this logic directly from mio, later on.

[lucab]

I got busy with many other things in life, but the good news is that in the meanwhile bind_addr() and connect_addr() got stabilized in Rust 1.70. The additional methods in this patch already use the same signatures.

I've rebased and de-conflicted this PR, it should be ready for reviewing and merging, PTAL.

[Thomasdezeeuw]

One question, otherwise LGTM.

[Thomasdezeeuw]

Thanks @lucab