Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

No problem, it also suggests somebody seriously interested in the 32-bit
emulation  might find entertaining running regression tests both natively
and in the i386->amd64 mode comparing results, it could bring some
interesting corner cases and pitfalls of the compat/freebsd32 to light.
I've also made some generic improvements into the udp_pingpong to catch
anomality in returned data length as well as to handle MSG_CTRUNC and
premature departure of the other side more gracefully.

-Max

On Wed, Sep 6, 2017 at 2:31 PM, Alan Somers  wrote:

> Cool.  Thanks for looking into it.
>
> On Wed, Sep 6, 2017 at 3:15 PM, Maxim Sobolev  wrote:
> > Alan, I doubt SO_BINTIME / SO_TIMESTAMP ever worked in that scenario. The
> > reason for that is size/layout of the bintime (and other structs) is
> > different on amd64 as compared to i386 and I don't see any conversion
> going
> > on in the freebsd32_recvmsg().
> >
> >  i386  x86_64
> > sizeof(timeval) 8  16
> > sizeof(bintime)12  16
> > sizeof(timespec)8  16
> >
> > Thereby, first the buffer supplied by the i386 app is not going to be
> > sufficient (causing MSG_CTRUNC). Or even if the app on the receiving end
> > overcommits for whatever reason, it's not going to be able parse the
> > returned structures correctly. This is actually the case with the
> > udp_pingpong, that is also not working properly in emulation mode:
> >
> > [tools/regression/sockets/udp_pingpong]$ ./udp_pingpong
> > Testing send()/recv() via IPv4: OK
> > Testing send()/recvmsg(), setsockopt(SO_TIMESTAMP, 1) via IPv4:
> > udp_pingpong: A2B trip time is not positive
> >
> > Therefore, the i386 emulation code needs to be extended to actually parse
> > into cmghdr structure(s) and to do a proper type conversion between 32
> and
> > 64 bit versions of the struct timeval, struct bintime and struct
> timespec.
> >
> > I have a patch in works to get it fixed, stay tuned.
> >
> > -Max
> >
> > On Mon, Sep 4, 2017 at 7:09 PM, Maxim Sobolev 
> wrote:
> >>
> >> Sure, I'll check that out. Thanks for heads up.
> >>
> >> -Max
> >>
> >> On Sun, Sep 3, 2017 at 8:18 PM, Alan Somers 
> wrote:
> >>>
> >>> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev 
> >>> wrote:
> >>> > Author: sobomax
> >>> > Date: Mon Jan 16 17:46:38 2017
> >>> > New Revision: 312296
> >>> > URL: https://svnweb.freebsd.org/changeset/base/312296
> >>> >
> >>> > Log:
> >>> >   Add a new socket option SO_TS_CLOCK to pick from several different
> >>> > clock
> >>> >   sources to return timestamps when SO_TIMESTAMP is enabled. Two
> >>> > additional
> >>> >   clock sources are:
> >>> >
> >>> >   o nanosecond resolution realtime clock (equivalent of
> >>> > CLOCK_REALTIME);
> >>> >   o nanosecond resolution monotonic clock (equivalent of
> >>> > CLOCK_MONOTONIC).
> >>> >
> >>> >   In addition to this, this option provides unified interface to get
> >>> > bintime
> >>> >   (equivalent of using SO_BINTIME), except it also supported with
> IPv6
> >>> > where
> >>> >   SO_BINTIME has never been supported. The long term plan is to
> >>> > depreciate
> >>> >   SO_BINTIME and move everything to using SO_TS_CLOCK.
> >>> >
> >>> >   Idea for this enhancement has been briefly discussed on the Net
> >>> > session
> >>> >   during dev summit in Ottawa last June and the general input was
> >>> > positive.
> >>> >
> >>> >   This change is believed to benefit network benchmarks/profiling as
> >>> > well
> >>> >   as other scenarios where precise time of arrival measurement is
> >>> > necessary.
> >>> >
> >>> >   There are two regression test cases as part of this commit: one
> >>> > extends unix
> >>> >   domain test code (unix_cmsg) to test new SCM_XXX types and another
> >>> > one
> >>> >   implementis totally new test case which exchanges UDP packets
> between
> >>> > two
> >>> >   processes using both conventional methods (i.e. calling
> >>> > clock_gettime(2)
> >>> >   before recv(2) and after send(2)), as well as using
> >>> > setsockopt()+recv() in
> >>> >   receive path. The resulting delays are checked for sanity for all
> >>> > supported
> >>> >   clock types.
> >>> >
> >>> >   Reviewed by:adrian, gnn
> >>> >   Differential Revision:  https://reviews.freebsd.org/D9171
> >>>
> >>> While the new SCM_TIMESTAMP code works fine on both amd64 and i386, it
> >>> doesn't work on amd64 under 32-bit emulation.  That is, programs that
> >>> use SCM_TIMESTAMP built for i386 will fail when run on an amd64
> >>> machine.  I don't know whether this commit introduced that bug; on
> >>> stable-10 SCM_TIMESTAMP doesn't appear to work at all on i386.  But
> >>> sobomax, since you're obviously familiar with this code, would you
> >>> mind taking a look?
> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222039
> >>>
> >>> -Alan
> >>>
> >>
> >
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-u

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Alan Somers]

Cool.  Thanks for looking into it.

On Wed, Sep 6, 2017 at 3:15 PM, Maxim Sobolev  wrote:
> Alan, I doubt SO_BINTIME / SO_TIMESTAMP ever worked in that scenario. The
> reason for that is size/layout of the bintime (and other structs) is
> different on amd64 as compared to i386 and I don't see any conversion going
> on in the freebsd32_recvmsg().
>
>  i386  x86_64
> sizeof(timeval) 8  16
> sizeof(bintime)12  16
> sizeof(timespec)8  16
>
> Thereby, first the buffer supplied by the i386 app is not going to be
> sufficient (causing MSG_CTRUNC). Or even if the app on the receiving end
> overcommits for whatever reason, it's not going to be able parse the
> returned structures correctly. This is actually the case with the
> udp_pingpong, that is also not working properly in emulation mode:
>
> [tools/regression/sockets/udp_pingpong]$ ./udp_pingpong
> Testing send()/recv() via IPv4: OK
> Testing send()/recvmsg(), setsockopt(SO_TIMESTAMP, 1) via IPv4:
> udp_pingpong: A2B trip time is not positive
>
> Therefore, the i386 emulation code needs to be extended to actually parse
> into cmghdr structure(s) and to do a proper type conversion between 32 and
> 64 bit versions of the struct timeval, struct bintime and struct timespec.
>
> I have a patch in works to get it fixed, stay tuned.
>
> -Max
>
> On Mon, Sep 4, 2017 at 7:09 PM, Maxim Sobolev  wrote:
>>
>> Sure, I'll check that out. Thanks for heads up.
>>
>> -Max
>>
>> On Sun, Sep 3, 2017 at 8:18 PM, Alan Somers  wrote:
>>>
>>> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev 
>>> wrote:
>>> > Author: sobomax
>>> > Date: Mon Jan 16 17:46:38 2017
>>> > New Revision: 312296
>>> > URL: https://svnweb.freebsd.org/changeset/base/312296
>>> >
>>> > Log:
>>> >   Add a new socket option SO_TS_CLOCK to pick from several different
>>> > clock
>>> >   sources to return timestamps when SO_TIMESTAMP is enabled. Two
>>> > additional
>>> >   clock sources are:
>>> >
>>> >   o nanosecond resolution realtime clock (equivalent of
>>> > CLOCK_REALTIME);
>>> >   o nanosecond resolution monotonic clock (equivalent of
>>> > CLOCK_MONOTONIC).
>>> >
>>> >   In addition to this, this option provides unified interface to get
>>> > bintime
>>> >   (equivalent of using SO_BINTIME), except it also supported with IPv6
>>> > where
>>> >   SO_BINTIME has never been supported. The long term plan is to
>>> > depreciate
>>> >   SO_BINTIME and move everything to using SO_TS_CLOCK.
>>> >
>>> >   Idea for this enhancement has been briefly discussed on the Net
>>> > session
>>> >   during dev summit in Ottawa last June and the general input was
>>> > positive.
>>> >
>>> >   This change is believed to benefit network benchmarks/profiling as
>>> > well
>>> >   as other scenarios where precise time of arrival measurement is
>>> > necessary.
>>> >
>>> >   There are two regression test cases as part of this commit: one
>>> > extends unix
>>> >   domain test code (unix_cmsg) to test new SCM_XXX types and another
>>> > one
>>> >   implementis totally new test case which exchanges UDP packets between
>>> > two
>>> >   processes using both conventional methods (i.e. calling
>>> > clock_gettime(2)
>>> >   before recv(2) and after send(2)), as well as using
>>> > setsockopt()+recv() in
>>> >   receive path. The resulting delays are checked for sanity for all
>>> > supported
>>> >   clock types.
>>> >
>>> >   Reviewed by:adrian, gnn
>>> >   Differential Revision:  https://reviews.freebsd.org/D9171
>>>
>>> While the new SCM_TIMESTAMP code works fine on both amd64 and i386, it
>>> doesn't work on amd64 under 32-bit emulation.  That is, programs that
>>> use SCM_TIMESTAMP built for i386 will fail when run on an amd64
>>> machine.  I don't know whether this commit introduced that bug; on
>>> stable-10 SCM_TIMESTAMP doesn't appear to work at all on i386.  But
>>> sobomax, since you're obviously familiar with this code, would you
>>> mind taking a look?
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222039
>>>
>>> -Alan
>>>
>>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Alan, I doubt SO_BINTIME / SO_TIMESTAMP ever worked in that scenario. The
reason for that is size/layout of the bintime (and other structs) is
different on amd64 as compared to i386 and I don't see any conversion going
on in the freebsd32_recvmsg().

 i386  x86_64
sizeof(timeval) 8  16
sizeof(bintime)12  16
sizeof(timespec)8  16

Thereby, first the buffer supplied by the i386 app is not going to be
sufficient (causing MSG_CTRUNC). Or even if the app on the receiving end
overcommits for whatever reason, it's not going to be able parse the
returned structures correctly. This is actually the case with the
udp_pingpong, that is also not working properly in emulation mode:

[tools/regression/sockets/udp_pingpong]$ ./udp_pingpong
Testing send()/recv() via IPv4: OK
Testing send()/recvmsg(), setsockopt(SO_TIMESTAMP, 1) via IPv4:
udp_pingpong: A2B trip time is not positive

Therefore, the i386 emulation code needs to be extended to actually parse
into cmghdr structure(s) and to do a proper type conversion between 32 and
64 bit versions of the struct timeval, struct bintime and struct timespec.

I have a patch in works to get it fixed, stay tuned.

-Max

On Mon, Sep 4, 2017 at 7:09 PM, Maxim Sobolev  wrote:

> Sure, I'll check that out. Thanks for heads up.
>
> -Max
>
> On Sun, Sep 3, 2017 at 8:18 PM, Alan Somers  wrote:
>
>> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev 
>> wrote:
>> > Author: sobomax
>> > Date: Mon Jan 16 17:46:38 2017
>> > New Revision: 312296
>> > URL: https://svnweb.freebsd.org/changeset/base/312296
>> >
>> > Log:
>> >   Add a new socket option SO_TS_CLOCK to pick from several different
>> clock
>> >   sources to return timestamps when SO_TIMESTAMP is enabled. Two
>> additional
>> >   clock sources are:
>> >
>> >   o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
>> >   o nanosecond resolution monotonic clock (equivalent of
>> CLOCK_MONOTONIC).
>> >
>> >   In addition to this, this option provides unified interface to get
>> bintime
>> >   (equivalent of using SO_BINTIME), except it also supported with IPv6
>> where
>> >   SO_BINTIME has never been supported. The long term plan is to
>> depreciate
>> >   SO_BINTIME and move everything to using SO_TS_CLOCK.
>> >
>> >   Idea for this enhancement has been briefly discussed on the Net
>> session
>> >   during dev summit in Ottawa last June and the general input was
>> positive.
>> >
>> >   This change is believed to benefit network benchmarks/profiling as
>> well
>> >   as other scenarios where precise time of arrival measurement is
>> necessary.
>> >
>> >   There are two regression test cases as part of this commit: one
>> extends unix
>> >   domain test code (unix_cmsg) to test new SCM_XXX types and another one
>> >   implementis totally new test case which exchanges UDP packets between
>> two
>> >   processes using both conventional methods (i.e. calling
>> clock_gettime(2)
>> >   before recv(2) and after send(2)), as well as using
>> setsockopt()+recv() in
>> >   receive path. The resulting delays are checked for sanity for all
>> supported
>> >   clock types.
>> >
>> >   Reviewed by:adrian, gnn
>> >   Differential Revision:  https://reviews.freebsd.org/D9171
>>
>> While the new SCM_TIMESTAMP code works fine on both amd64 and i386, it
>> doesn't work on amd64 under 32-bit emulation.  That is, programs that
>> use SCM_TIMESTAMP built for i386 will fail when run on an amd64
>> machine.  I don't know whether this commit introduced that bug; on
>> stable-10 SCM_TIMESTAMP doesn't appear to work at all on i386.  But
>> sobomax, since you're obviously familiar with this code, would you
>> mind taking a look?
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222039
>>
>> -Alan
>>
>>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Sure, I'll check that out. Thanks for heads up.

-Max

On Sun, Sep 3, 2017 at 8:18 PM, Alan Somers  wrote:

> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev 
> wrote:
> > Author: sobomax
> > Date: Mon Jan 16 17:46:38 2017
> > New Revision: 312296
> > URL: https://svnweb.freebsd.org/changeset/base/312296
> >
> > Log:
> >   Add a new socket option SO_TS_CLOCK to pick from several different
> clock
> >   sources to return timestamps when SO_TIMESTAMP is enabled. Two
> additional
> >   clock sources are:
> >
> >   o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
> >   o nanosecond resolution monotonic clock (equivalent of
> CLOCK_MONOTONIC).
> >
> >   In addition to this, this option provides unified interface to get
> bintime
> >   (equivalent of using SO_BINTIME), except it also supported with IPv6
> where
> >   SO_BINTIME has never been supported. The long term plan is to
> depreciate
> >   SO_BINTIME and move everything to using SO_TS_CLOCK.
> >
> >   Idea for this enhancement has been briefly discussed on the Net session
> >   during dev summit in Ottawa last June and the general input was
> positive.
> >
> >   This change is believed to benefit network benchmarks/profiling as well
> >   as other scenarios where precise time of arrival measurement is
> necessary.
> >
> >   There are two regression test cases as part of this commit: one
> extends unix
> >   domain test code (unix_cmsg) to test new SCM_XXX types and another one
> >   implementis totally new test case which exchanges UDP packets between
> two
> >   processes using both conventional methods (i.e. calling
> clock_gettime(2)
> >   before recv(2) and after send(2)), as well as using
> setsockopt()+recv() in
> >   receive path. The resulting delays are checked for sanity for all
> supported
> >   clock types.
> >
> >   Reviewed by:adrian, gnn
> >   Differential Revision:  https://reviews.freebsd.org/D9171
>
> While the new SCM_TIMESTAMP code works fine on both amd64 and i386, it
> doesn't work on amd64 under 32-bit emulation.  That is, programs that
> use SCM_TIMESTAMP built for i386 will fail when run on an amd64
> machine.  I don't know whether this commit introduced that bug; on
> stable-10 SCM_TIMESTAMP doesn't appear to work at all on i386.  But
> sobomax, since you're obviously familiar with this code, would you
> mind taking a look?
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222039
>
> -Alan
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Alan Somers]

On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev  wrote:
> Author: sobomax
> Date: Mon Jan 16 17:46:38 2017
> New Revision: 312296
> URL: https://svnweb.freebsd.org/changeset/base/312296
>
> Log:
>   Add a new socket option SO_TS_CLOCK to pick from several different clock
>   sources to return timestamps when SO_TIMESTAMP is enabled. Two additional
>   clock sources are:
>
>   o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
>   o nanosecond resolution monotonic clock (equivalent of CLOCK_MONOTONIC).
>
>   In addition to this, this option provides unified interface to get bintime
>   (equivalent of using SO_BINTIME), except it also supported with IPv6 where
>   SO_BINTIME has never been supported. The long term plan is to depreciate
>   SO_BINTIME and move everything to using SO_TS_CLOCK.
>
>   Idea for this enhancement has been briefly discussed on the Net session
>   during dev summit in Ottawa last June and the general input was positive.
>
>   This change is believed to benefit network benchmarks/profiling as well
>   as other scenarios where precise time of arrival measurement is necessary.
>
>   There are two regression test cases as part of this commit: one extends unix
>   domain test code (unix_cmsg) to test new SCM_XXX types and another one
>   implementis totally new test case which exchanges UDP packets between two
>   processes using both conventional methods (i.e. calling clock_gettime(2)
>   before recv(2) and after send(2)), as well as using setsockopt()+recv() in
>   receive path. The resulting delays are checked for sanity for all supported
>   clock types.
>
>   Reviewed by:adrian, gnn
>   Differential Revision:  https://reviews.freebsd.org/D9171

While the new SCM_TIMESTAMP code works fine on both amd64 and i386, it
doesn't work on amd64 under 32-bit emulation.  That is, programs that
use SCM_TIMESTAMP built for i386 will fail when run on an amd64
machine.  I don't know whether this commit introduced that bug; on
stable-10 SCM_TIMESTAMP doesn't appear to work at all on i386.  But
sobomax, since you're obviously familiar with this code, would you
mind taking a look?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222039

-Alan
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Ngie Cooper (yaneurabeya)]

> On Jan 17, 2017, at 17:42, Daniel Eischen  wrote:
> 
> On Tue, 17 Jan 2017, Maxim Sobolev wrote:
> 
>> Also there is at least one thing that makes enum less desirable from the
>> point of view of application developer. Particularly it makes it impossible
>> to use preprocessor to do a conditional compilation, which is especially
>> important for the FreeBSD-specific options. With the "old" way, I can
>> easily have something like:
>> 
>> #if defined(SO_TS_CLOCK)
>> ...
>> setsockopt(SO_TS_CLOCK, ...);
>> #else
>> [do something else]
>> #endif
>> 
>> This does not work with enums for obvious reasons, one would need to resort
>> to using some kind of autoconfigure mechanism to figure out if the enum in
>> question is defined.
> 
> Great point, we (at $JOB) have code that this, and would break
> if changed to enums.

I’m not saying enums would be a bad idea, but it would require more 
work on the autoconf end as well, and would make testing for these symbols' 
support a little less straightforward.
Maybe a combination of #define’s for determining whether or not the 
support is present, i.e. for simple #ifdef folks (I would probably only use one 
though), and having a sample for testing for support in autoconf in some 
products would be beneficial?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Daniel Eischen]

On Tue, 17 Jan 2017, Maxim Sobolev wrote:


Also there is at least one thing that makes enum less desirable from the
point of view of application developer. Particularly it makes it impossible
to use preprocessor to do a conditional compilation, which is especially
important for the FreeBSD-specific options. With the "old" way, I can
easily have something like:

#if defined(SO_TS_CLOCK)
...
setsockopt(SO_TS_CLOCK, ...);
#else
[do something else]
#endif

This does not work with enums for obvious reasons, one would need to resort
to using some kind of autoconfigure mechanism to figure out if the enum in
question is defined.


Great point, we (at $JOB) have code that this, and would break
if changed to enums.

--
DE
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

OK, guys, with all due respect I think I've heard enough to say that if
somebody feels like this has to be enum feel free to jump in and tweak it
out. As far as I understand there should be no user-visible differences
either way, so it's not like we are going to be locked with this way
forever. It's never too late to revise it (and it's FreeBSD-specific
interface as well). Requesting me to implement something that it is at
least a bit controversial and also something completely orthogonal to the
original functionality and which I have no idea how to do/test properly on
top of what's been done already is a bit overboard I would say.

In my view, if we are to convert set/getsockopt(2) to enums it has to do in
one shot and tested against large set of third-party software to make sure
it won't bring out some corner cases (i.e. some unhandled values in
switch() statements and the likes, C++ breakage, weird compilers, #ifdef
blocks etc). If some developer(s) feel #define is an old way no longer
relevant in 2017 the onus has to be on those to come up with a patch and go
though the heat of defending it against other set of developers who don't
share that opinion. Pushing me, who is largely ambivalent to either way, to
do it is not fair. It's like asking mechanic who works on fixing
your brakes to also paint your calipers for aesthetic reasons for the same
price. Not even to mention that the change in question has been on reviews
and received positive feedback from other developers working in the same
area (e.g. gnn) and none of the enum guys paid any attention until it hit
the tree.

Also there is at least one thing that makes enum less desirable from the
point of view of application developer. Particularly it makes it impossible
to use preprocessor to do a conditional compilation, which is especially
important for the FreeBSD-specific options. With the "old" way, I can
easily have something like:

#if defined(SO_TS_CLOCK)
...
setsockopt(SO_TS_CLOCK, ...);
#else
[do something else]
#endif

This does not work with enums for obvious reasons, one would need to resort
to using some kind of autoconfigure mechanism to figure out if the enum in
question is defined.

-Max

On Tue, Jan 17, 2017 at 3:52 PM, Ian Lepore  wrote:

> I actually don't agree that it's all good, but I also don't have the
> time to prove it's not (or prove myself wrong, which could certainly be
> the case).
>
> -- Ian
>
> On Tue, 2017-01-17 at 15:21 -0800, Conrad Meyer wrote:
> > Ian's potential objection has been met by Ben Kaduk and Eric van
> > Gyzen's responses.  It seems like an enum is just fine.  And I agree
> > with Gleb that it is preferable.
> >
> > Conrad
> >
> > On Tue, Jan 17, 2017 at 1:34 PM, Maxim Sobolev 
> > wrote:
> > >
> > > Well as other pointed out there are some concerns with using enums
> > > from C++
> > > and ABI prospective. So it looks to me that there is no general
> > > consensus on
> > > that direction.
> > >
> > > -Max
> > >
> > > On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff  > > > wrote:
> > > >
> > > >
> > > > On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
> > > > M> That being said, is there any other socket option value in
> > > > there
> > > > M> implemented as enum? I don't see anything obvious, so that I
> > > > am curious
> > > > if
> > > > M> it would stick out as an odd one in there. What do you think?
> > > >
> > > > Simply because 30 years ago the language didn't allow that, and
> > > > later
> > > > additions mimiced the older sockopts. We need to break this loop
> > > > :)
> > > >
> > > > --
> > > > Totus tuus, Glebius.
> > > >
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Ian Lepore]

I actually don't agree that it's all good, but I also don't have the
time to prove it's not (or prove myself wrong, which could certainly be
the case).

-- Ian

On Tue, 2017-01-17 at 15:21 -0800, Conrad Meyer wrote:
> Ian's potential objection has been met by Ben Kaduk and Eric van
> Gyzen's responses.  It seems like an enum is just fine.  And I agree
> with Gleb that it is preferable.
> 
> Conrad
> 
> On Tue, Jan 17, 2017 at 1:34 PM, Maxim Sobolev 
> wrote:
> > 
> > Well as other pointed out there are some concerns with using enums
> > from C++
> > and ABI prospective. So it looks to me that there is no general
> > consensus on
> > that direction.
> > 
> > -Max
> > 
> > On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff  > > wrote:
> > > 
> > > 
> > > On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
> > > M> That being said, is there any other socket option value in
> > > there
> > > M> implemented as enum? I don't see anything obvious, so that I
> > > am curious
> > > if
> > > M> it would stick out as an odd one in there. What do you think?
> > > 
> > > Simply because 30 years ago the language didn't allow that, and
> > > later
> > > additions mimiced the older sockopts. We need to break this loop
> > > :)
> > > 
> > > --
> > > Totus tuus, Glebius.
> > > 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Conrad Meyer]

Ian's potential objection has been met by Ben Kaduk and Eric van
Gyzen's responses.  It seems like an enum is just fine.  And I agree
with Gleb that it is preferable.

Conrad

On Tue, Jan 17, 2017 at 1:34 PM, Maxim Sobolev  wrote:
> Well as other pointed out there are some concerns with using enums from C++
> and ABI prospective. So it looks to me that there is no general consensus on
> that direction.
>
> -Max
>
> On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff  wrote:
>>
>> On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
>> M> That being said, is there any other socket option value in there
>> M> implemented as enum? I don't see anything obvious, so that I am curious
>> if
>> M> it would stick out as an odd one in there. What do you think?
>>
>> Simply because 30 years ago the language didn't allow that, and later
>> additions mimiced the older sockopts. We need to break this loop :)
>>
>> --
>> Totus tuus, Glebius.
>>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Well as other pointed out there are some concerns with using enums from C++
and ABI prospective. So it looks to me that there is no general consensus
on that direction.

-Max

On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff  wrote:

> On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
> M> That being said, is there any other socket option value in there
> M> implemented as enum? I don't see anything obvious, so that I am curious
> if
> M> it would stick out as an odd one in there. What do you think?
>
> Simply because 30 years ago the language didn't allow that, and later
> additions mimiced the older sockopts. We need to break this loop :)
>
> --
> Totus tuus, Glebius.
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Gleb Smirnoff]

On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
M> That being said, is there any other socket option value in there
M> implemented as enum? I don't see anything obvious, so that I am curious if
M> it would stick out as an odd one in there. What do you think?

Simply because 30 years ago the language didn't allow that, and later
additions mimiced the older sockopts. We need to break this loop :)

-- 
Totus tuus, Glebius.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Eric van Gyzen]

On 01/17/2017 11:48, Benjamin Kaduk wrote:
> On Tue, Jan 17, 2017 at 10:57 AM, Ian Lepore  > wrote:
> 
> In my experience, enums are a superior way to define integer constants
> (compared to #define), but they are pure poison as variable types in
> APIs and structures because their size is a compiler implementation
> choice.
> 
> 
> Well, to some extent. For example, the amd64 sysV ABI says that enum
> types are signed fourbyte, with a footnote that "C++ and some
> implementations of C permit enums larger than an int. The underlying
> type is bumped to an unsigned int, long int or unsigned long int, in
> that order."

And in C++11 and later, you can specify the exact type:

enum color
#if defined(__cplusplus) && __cplusplus >= 201103L
: int
#endif
{
blue,
...

Eric
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Benjamin Kaduk]

On Tue, Jan 17, 2017 at 10:57 AM, Ian Lepore  wrote:

> In my experience, enums are a superior way to define integer constants
> (compared to #define), but they are pure poison as variable types in
> APIs and structures because their size is a compiler implementation
> choice.
>

Well, to some extent. For example, the amd64 sysV ABI says that enum types
are signed fourbyte, with a footnote that "C++ and some implementations of
C permit enums larger than an int. The underlying type is bumped to an
unsigned int, long int or unsigned long int, in that order."

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Ian Lepore]

In my experience, enums are a superior way to define integer constants
(compared to #define), but they are pure poison as variable types in
APIs and structures because their size is a compiler implementation
choice.

-- Ian

On Tue, 2017-01-17 at 08:40 -0800, Maxim Sobolev wrote:
> That being said, is there any other socket option value in there
> implemented as enum? I don't see anything obvious, so that I am
> curious if
> it would stick out as an odd one in there. What do you think?
> 
> -Max
> 
> On Tue, Jan 17, 2017 at 6:22 AM, Maxim Sobolev 
> wrote:
> 
> > 
> > Of course it's possible. Do you guys want me to amend that patch?
> > 
> > -Max
> > 
> > On Mon, Jan 16, 2017 at 10:52 PM, Gleb Smirnoff  > g>
> > wrote:
> > 
> > > 
> > >   Hi!
> > > 
> > > On Mon, Jan 16, 2017 at 05:46:38PM +, Maxim Sobolev wrote:
> > > M> Author: sobomax
> > > M> Date: Mon Jan 16 17:46:38 2017
> > > M> New Revision: 312296
> > > M> URL: https://svnweb.freebsd.org/changeset/base/312296
> > > M>
> > > M> Log:
> > > M>   Add a new socket option SO_TS_CLOCK to pick from several
> > > different
> > > clock
> > > M>   sources to return timestamps when SO_TIMESTAMP is enabled.
> > > Two
> > > additional
> > > M>   clock sources are:
> > > M>
> > > M>   o nanosecond resolution realtime clock (equivalent of
> > > CLOCK_REALTIME);
> > > M>   o nanosecond resolution monotonic clock (equivalent of
> > > CLOCK_MONOTONIC).
> > > M>
> > > M>   In addition to this, this option provides unified interface
> > > to get
> > > bintime
> > > M>   (equivalent of using SO_BINTIME), except it also supported
> > > with IPv6
> > > where
> > > M>   SO_BINTIME has never been supported. The long term plan is
> > > to
> > > depreciate
> > > M>   SO_BINTIME and move everything to using SO_TS_CLOCK.
> > > M>
> > > M>   Idea for this enhancement has been briefly discussed on the
> > > Net
> > > session
> > > M>   during dev summit in Ottawa last June and the general input
> > > was
> > > positive.
> > > M>
> > > M>   This change is believed to benefit network
> > > benchmarks/profiling as
> > > well
> > > M>   as other scenarios where precise time of arrival measurement
> > > is
> > > necessary.
> > > M>
> > > M>   There are two regression test cases as part of this commit:
> > > one
> > > extends unix
> > > M>   domain test code (unix_cmsg) to test new SCM_XXX types and
> > > another
> > > one
> > > M>   implementis totally new test case which exchanges UDP
> > > packets
> > > between two
> > > M>   processes using both conventional methods (i.e. calling
> > > clock_gettime(2)
> > > M>   before recv(2) and after send(2)), as well as using
> > > setsockopt()+recv() in
> > > M>   receive path. The resulting delays are checked for sanity
> > > for all
> > > supported
> > > M>   clock types.
> > > M>
> > > M>   Reviewed by:adrian, gnn
> > > M>   Differential Revision:  https://reviews.freebsd.org/D9171
> > > 
> > > Is it possible to declare possible values as a enum and make
> > > so_ts_clock
> > > fields of that enum type?
> > > 
> > > --
> > > Totus tuus, Glebius.
> > > 
> > > 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

That being said, is there any other socket option value in there
implemented as enum? I don't see anything obvious, so that I am curious if
it would stick out as an odd one in there. What do you think?

-Max

On Tue, Jan 17, 2017 at 6:22 AM, Maxim Sobolev  wrote:

> Of course it's possible. Do you guys want me to amend that patch?
>
> -Max
>
> On Mon, Jan 16, 2017 at 10:52 PM, Gleb Smirnoff 
> wrote:
>
>>   Hi!
>>
>> On Mon, Jan 16, 2017 at 05:46:38PM +, Maxim Sobolev wrote:
>> M> Author: sobomax
>> M> Date: Mon Jan 16 17:46:38 2017
>> M> New Revision: 312296
>> M> URL: https://svnweb.freebsd.org/changeset/base/312296
>> M>
>> M> Log:
>> M>   Add a new socket option SO_TS_CLOCK to pick from several different
>> clock
>> M>   sources to return timestamps when SO_TIMESTAMP is enabled. Two
>> additional
>> M>   clock sources are:
>> M>
>> M>   o nanosecond resolution realtime clock (equivalent of
>> CLOCK_REALTIME);
>> M>   o nanosecond resolution monotonic clock (equivalent of
>> CLOCK_MONOTONIC).
>> M>
>> M>   In addition to this, this option provides unified interface to get
>> bintime
>> M>   (equivalent of using SO_BINTIME), except it also supported with IPv6
>> where
>> M>   SO_BINTIME has never been supported. The long term plan is to
>> depreciate
>> M>   SO_BINTIME and move everything to using SO_TS_CLOCK.
>> M>
>> M>   Idea for this enhancement has been briefly discussed on the Net
>> session
>> M>   during dev summit in Ottawa last June and the general input was
>> positive.
>> M>
>> M>   This change is believed to benefit network benchmarks/profiling as
>> well
>> M>   as other scenarios where precise time of arrival measurement is
>> necessary.
>> M>
>> M>   There are two regression test cases as part of this commit: one
>> extends unix
>> M>   domain test code (unix_cmsg) to test new SCM_XXX types and another
>> one
>> M>   implementis totally new test case which exchanges UDP packets
>> between two
>> M>   processes using both conventional methods (i.e. calling
>> clock_gettime(2)
>> M>   before recv(2) and after send(2)), as well as using
>> setsockopt()+recv() in
>> M>   receive path. The resulting delays are checked for sanity for all
>> supported
>> M>   clock types.
>> M>
>> M>   Reviewed by:adrian, gnn
>> M>   Differential Revision:  https://reviews.freebsd.org/D9171
>>
>> Is it possible to declare possible values as a enum and make so_ts_clock
>> fields of that enum type?
>>
>> --
>> Totus tuus, Glebius.
>>
>>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Of course it's possible. Do you guys want me to amend that patch?

-Max

On Mon, Jan 16, 2017 at 10:52 PM, Gleb Smirnoff  wrote:

>   Hi!
>
> On Mon, Jan 16, 2017 at 05:46:38PM +, Maxim Sobolev wrote:
> M> Author: sobomax
> M> Date: Mon Jan 16 17:46:38 2017
> M> New Revision: 312296
> M> URL: https://svnweb.freebsd.org/changeset/base/312296
> M>
> M> Log:
> M>   Add a new socket option SO_TS_CLOCK to pick from several different
> clock
> M>   sources to return timestamps when SO_TIMESTAMP is enabled. Two
> additional
> M>   clock sources are:
> M>
> M>   o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
> M>   o nanosecond resolution monotonic clock (equivalent of
> CLOCK_MONOTONIC).
> M>
> M>   In addition to this, this option provides unified interface to get
> bintime
> M>   (equivalent of using SO_BINTIME), except it also supported with IPv6
> where
> M>   SO_BINTIME has never been supported. The long term plan is to
> depreciate
> M>   SO_BINTIME and move everything to using SO_TS_CLOCK.
> M>
> M>   Idea for this enhancement has been briefly discussed on the Net
> session
> M>   during dev summit in Ottawa last June and the general input was
> positive.
> M>
> M>   This change is believed to benefit network benchmarks/profiling as
> well
> M>   as other scenarios where precise time of arrival measurement is
> necessary.
> M>
> M>   There are two regression test cases as part of this commit: one
> extends unix
> M>   domain test code (unix_cmsg) to test new SCM_XXX types and another one
> M>   implementis totally new test case which exchanges UDP packets between
> two
> M>   processes using both conventional methods (i.e. calling
> clock_gettime(2)
> M>   before recv(2) and after send(2)), as well as using
> setsockopt()+recv() in
> M>   receive path. The resulting delays are checked for sanity for all
> supported
> M>   clock types.
> M>
> M>   Reviewed by:adrian, gnn
> M>   Differential Revision:  https://reviews.freebsd.org/D9171
>
> Is it possible to declare possible values as a enum and make so_ts_clock
> fields of that enum type?
>
> --
> Totus tuus, Glebius.
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Gleb Smirnoff]

  Hi!

On Mon, Jan 16, 2017 at 05:46:38PM +, Maxim Sobolev wrote:
M> Author: sobomax
M> Date: Mon Jan 16 17:46:38 2017
M> New Revision: 312296
M> URL: https://svnweb.freebsd.org/changeset/base/312296
M> 
M> Log:
M>   Add a new socket option SO_TS_CLOCK to pick from several different clock
M>   sources to return timestamps when SO_TIMESTAMP is enabled. Two additional
M>   clock sources are:
M>   
M>   o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
M>   o nanosecond resolution monotonic clock (equivalent of CLOCK_MONOTONIC).
M>   
M>   In addition to this, this option provides unified interface to get bintime
M>   (equivalent of using SO_BINTIME), except it also supported with IPv6 where
M>   SO_BINTIME has never been supported. The long term plan is to depreciate
M>   SO_BINTIME and move everything to using SO_TS_CLOCK.
M>   
M>   Idea for this enhancement has been briefly discussed on the Net session
M>   during dev summit in Ottawa last June and the general input was positive.
M>   
M>   This change is believed to benefit network benchmarks/profiling as well
M>   as other scenarios where precise time of arrival measurement is necessary.
M>   
M>   There are two regression test cases as part of this commit: one extends 
unix
M>   domain test code (unix_cmsg) to test new SCM_XXX types and another one
M>   implementis totally new test case which exchanges UDP packets between two
M>   processes using both conventional methods (i.e. calling clock_gettime(2)
M>   before recv(2) and after send(2)), as well as using setsockopt()+recv() in
M>   receive path. The resulting delays are checked for sanity for all supported
M>   clock types.
M>   
M>   Reviewed by:adrian, gnn
M>   Differential Revision:  https://reviews.freebsd.org/D9171

Is it possible to declare possible values as a enum and make so_ts_clock
fields of that enum type?

-- 
Totus tuus, Glebius.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Author: sobomax
Date: Mon Jan 16 17:46:38 2017
New Revision: 312296
URL: https://svnweb.freebsd.org/changeset/base/312296

Log:
  Add a new socket option SO_TS_CLOCK to pick from several different clock
  sources to return timestamps when SO_TIMESTAMP is enabled. Two additional
  clock sources are:
  
  o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
  o nanosecond resolution monotonic clock (equivalent of CLOCK_MONOTONIC).
  
  In addition to this, this option provides unified interface to get bintime
  (equivalent of using SO_BINTIME), except it also supported with IPv6 where
  SO_BINTIME has never been supported. The long term plan is to depreciate
  SO_BINTIME and move everything to using SO_TS_CLOCK.
  
  Idea for this enhancement has been briefly discussed on the Net session
  during dev summit in Ottawa last June and the general input was positive.
  
  This change is believed to benefit network benchmarks/profiling as well
  as other scenarios where precise time of arrival measurement is necessary.
  
  There are two regression test cases as part of this commit: one extends unix
  domain test code (unix_cmsg) to test new SCM_XXX types and another one
  implementis totally new test case which exchanges UDP packets between two
  processes using both conventional methods (i.e. calling clock_gettime(2)
  before recv(2) and after send(2)), as well as using setsockopt()+recv() in
  receive path. The resulting delays are checked for sanity for all supported
  clock types.
  
  Reviewed by:adrian, gnn
  Differential Revision:  https://reviews.freebsd.org/D9171

Added:
  head/tools/regression/sockets/udp_pingpong/
  head/tools/regression/sockets/udp_pingpong/Makefile   (contents, props 
changed)
  head/tools/regression/sockets/udp_pingpong/udp_pingpong.c   (contents, props 
changed)
Modified:
  head/lib/libc/sys/getsockopt.2
  head/sys/kern/uipc_socket.c
  head/sys/kern/uipc_usrreq.c
  head/sys/netinet/ip_input.c
  head/sys/netinet6/ip6_input.c
  head/sys/sys/socket.h
  head/sys/sys/socketvar.h
  head/tools/regression/sockets/unix_cmsg/Makefile
  head/tools/regression/sockets/unix_cmsg/unix_cmsg.c

Modified: head/lib/libc/sys/getsockopt.2
==
--- head/lib/libc/sys/getsockopt.2  Mon Jan 16 17:43:43 2017
(r312295)
+++ head/lib/libc/sys/getsockopt.2  Mon Jan 16 17:46:38 2017
(r312296)
@@ -187,6 +187,7 @@ The following options are recognized in
 .It Dv SO_LISTENQLEN Ta "get complete queue length of the socket (get only)"
 .It Dv SO_LISTENINCQLEN Ta "get incomplete queue length of the socket (get 
only)"
 .It Dv SO_USER_COOKIE Ta "set the 'so_user_cookie' value for the socket 
(uint32_t, set only)"
+.It Dv SO_TS_CLOCK Ta "set specific format of timestamp returned by 
SO_TIMESTAMP"
 .El
 .Pp
 .Dv SO_DEBUG
@@ -435,7 +436,7 @@ for
 .Dv SO_BINTIME .
 The
 .Vt cmsghdr
-fields have the following values for TIMESTAMP:
+fields have the following values for TIMESTAMP by default:
 .Bd -literal
  cmsg_len = CMSG_LEN(sizeof(struct timeval));
  cmsg_level = SOL_SOCKET;
@@ -450,6 +451,24 @@ and for
  cmsg_type = SCM_BINTIME;
 .Ed
 .Pp
+Additional timestamp types are available by following
+.Dv SO_TIMESTAMP
+with
+.Dv SO_TS_CLOCK ,
+which requests specific timestamp format to be returned instead of
+.Dv SCM_TIMESTAMP when
+.Dv SO_TIMESTAMP is enabled.
+The following
+.Dv SO_TS_CLOCK
+values are recognized in
+.Fx :
+.Bl -column SO_TS_CLOCK -offset indent
+.It Dv SO_TS_REALTIME_MICRO Ta "realtime (SCM_TIMESTAMP, struct timeval), 
default"
+.It Dv SO_TS_BINTIME Ta "realtime (SCM_BINTIME, struct bintime)"
+.It Dv SO_TS_REALTIME Ta "realtime (SCM_REALTIME, struct timespec)"
+.It Dv SO_TS_MONOTONIC Ta "monotonic time (SCM_MONOTONIC, struct timespec)"
+.El
+.Pp
 .Dv SO_ACCEPTCONN ,
 .Dv SO_TYPE ,
 .Dv SO_PROTOCOL

Modified: head/sys/kern/uipc_socket.c
==
--- head/sys/kern/uipc_socket.c Mon Jan 16 17:43:43 2017(r312295)
+++ head/sys/kern/uipc_socket.c Mon Jan 16 17:46:38 2017(r312296)
@@ -2687,6 +2687,18 @@ sosetopt(struct socket *so, struct socko
 #endif
break;
 
+   case SO_TS_CLOCK:
+   error = sooptcopyin(sopt, &optval, sizeof optval,
+   sizeof optval);
+   if (error)
+   goto bad;
+   if (optval < 0 || optval > SO_TS_CLOCK_MAX) {
+   error = EINVAL;
+   goto bad;
+   }
+   so->so_ts_clock = optval;
+   break;
+
default:
if (V_socket_hhh[HHOOK_SOCKET_OPT]->hhh_nhooks > 0)
error = hhook_run_socket(so, sopt,
@@ -2874,6 +2886,10 @@ integer:
optval = so-