Date: Wed, 16 Nov 2016 17:38:02 -0800 From: Maxim Sobolev <sobomax@freebsd.org> To: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org> Subject: Adding variant of SO_TIMESTAMP: bumping so_options from short to int or some other way around? Message-ID: <CAH7qZfsiiB-hS_yUe1XgJnsvR9hu=HGQ=UDQVinFAV5bHZJeVw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi folks, we are working on some extra socket options, which is getting monotinic timestamps instead of realtime. That might be extremely useful in the Real World[tm] situations. Before looking at the code closely I've considered SO_TIMESTAMP_MT. But then and I've found that are are out of space already there are 16 options and all 16 seems to be actually referenced in the code. Would there be any objections to doubling that? The userland interfaces seems to be already "int", so we are talking about just some minor KABI breakage. Alternative approach would be to merge SO_TIMESTAMP and SO_BINTIME, which is FreeBSD-specific anyways into just SO_TIMESTAMP, so that one can do something like: int val = SO_TS_BINTIME; setsockopt(fd, SOL_SOCKET, SO_TIMESTAMP, &val, sizeof(val)); Then we can also have SO_TS_MONOTONIC, SO_TS_UPTIME etc. That second approach would be a bit heavy on third-party apps that might be using SO_BINTIME already, but some guards could be placed in to make such software to blow up in a meaningful fashion when trying to use SO_BINTIME. Third option would be to leave SO_BINTIME alone and just make SO_TIMESTAMP accept some magic value as SO_TS_MONOTONIC. That is probably the easiest, but also creates some documentation challenge to explain why mechanism for requesting "bintime" variant is different from "monotonic". My preference would be (2), since SO_BINTIME is historic relic and it should be just value for the SO_TIMESTAMP, not a separate option. Thanks! -Maxim P.S. On somewhat unrelated note I've also noticed that tcp_var uses u_short for its copy, is it my design or just some overlook? I don't see why would we want to use two different types for essentially the same thing. This is just calling for all sorts of weird bugs due to implied sign(edness) of resulting expressions. P.P.S. Please keep me on the CC, I am not subscribed to those two lists.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAH7qZfsiiB-hS_yUe1XgJnsvR9hu=HGQ=UDQVinFAV5bHZJeVw>