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 <sobo...@freebsd.org> > 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 <gleb...@freebsd.or > > g> > > wrote: > > > > > > > > Hi! > > > > > > On Mon, Jan 16, 2017 at 05:46:38PM +0000, 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"
