OK, after some more consideration, I'd probably go with scraping SO_BINTIME (FreeBSD private thing) and replacing it with SO_CLOCK which then would take type of clock as an argument, i.e.:
int val = SO_CLOCK_MONOTONIC; setsockopt(fd, SO_CLOCK, &val, sizeof(val)); or int val = SO_CLOCK_BINTIME; setsockopt(fd, SO_CLOCK, &val, sizeof(val)); Default value being SO_CLOCK_REALTIME. Then SO_TIMESTAMP could be just the on/off trigger so that there is consistency. We can keep SO_BINTIME around for binary compatibility too at least on the binary level by moving it into a kernel private name space. Regardless of this, I think so_options needs to be bumped up to match what user interface can accommodate (int, not short), makes no sense to "save"* 2 bytes per socket in 2016. The diff is here, reviewers are welcome. https://reviews.freebsd.org/D8582 -Max *) yes, I know it's not really saved perhaps due to alignment and such, hence "". On Wed, Nov 16, 2016 at 5:38 PM, Maxim Sobolev <sobo...@freebsd.org> wrote: > 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. > _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
