Adding `set_route` to `sys::unix::net`

[devnexen]

Proposal

Problem statement

Adding a separated set_route call from the existing set_mark.

Motivating examples or use cases

set_mark is more appropriate to assign an ID to a socket that a route can use, whereas set_route would set the route ID the socket is going to be bound to. The actual set_mark alone conflates a bit the two notions, thus adding FreeBSD's SO_SETFIB and OpenBSD's SO_RTABLE ought to migrate to the new call whereas Linux' SO_MARK (which the set_mark's idea generates from) and FreeBSD's SO_USER_COOKIE should remain.

Solution sketch

#[cfg(any(target_os("openbsd"), target_os("freebsd")))] pub fn set_route(&self, route: i32) -> io::Result<()> { ... <setsockopt with the platform specific constant> }

Alternatives

Links and related work

ref PR.

What happens now?

Possible responses

[workingjubilee]

Are there any existing libraries which have modeled this sort of binding? It's hard to judge whether this is appropriate, here.

[workingjubilee]

Alternatively, is there a particular reason std should do the bindings, instead of allowing such to live in a library?

[devnexen]

Are there any existing libraries which have modeled this sort of binding? It's hard to judge whether this is appropriate, here.

Apps tend to reimplement it each on their own, pretty straightforwardly for most since they do not necessarily need to be multi platform. I'd say setting the route it s a bit advanced usage but useful if you want the socket reaching it. And the necessary code is relatively simple.

[devnexen]

Alternatively, is there a particular reason std should do the bindings, instead of allowing such to live in a library?

That's a fair point, I'd say this kind of feature is kind of the limit of being relevant/irrelevant on being in rust std. If we were talking about Linux's BPF filter it would be clearly a bit much :-)

[asomers]

IMHO this is out-of-scope for the standard library. I think it would best live in a separate crate.

[the8472]

We discussed this briefly during today's libs-api meeting. Since a BSD target maintainer considers this out of scope for std we're going to follow their recommendation and reject this proposal.