Date: Sat, 19 Nov 2016 10:14:00 -0800 From: Maxim Sobolev <sobomax@freebsd.org> To: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Adding SO_CLOCK (replacing SO_BINTIME?). Message-ID: <CAH7qZfuwYweHXq1F4Lcfh2fg-Z=eK46UTdG_roN6gY9wFK=e7w@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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 <sobomax@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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAH7qZfuwYweHXq1F4Lcfh2fg-Z=eK46UTdG_roN6gY9wFK=e7w>