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

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

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

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

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, 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)

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

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:

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

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 >

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

> 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

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

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

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

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.

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

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

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'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

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

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,

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

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

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

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

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

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. >

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

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

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

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

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

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

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

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>

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

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