From owner-freebsd-net@freebsd.org Thu Nov 17 01:38:03 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 884D8C4598A for ; Thu, 17 Nov 2016 01:38:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55C7FC77 for ; Thu, 17 Nov 2016 01:38:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x232.google.com with SMTP id y23so9946151itc.0 for ; Wed, 16 Nov 2016 17:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=+aLWTSmeusXkO/h16fvvZMI3E2/PTcSxhwr2HZ0jKu4=; b=UA+KgnfC/3uSj34tUtPa/9CrSbQvGOsJTFZ4qB2c1esBgJXWOZAdzZA7QtCUxztQq6 ypMICjYHI/rEUHRjvDkpDHBUt+nsBD48rlOMwv1814LRgATBqHUmKG+q9raH47mgreXk 9ZkUQHu3ZobNrPL7Zsonc0FqIBpVNN+kKIGfh8OrQAmMt97o1dYqhmcp5wHI8gZCmL1X ZadtAjAes392flekdX6/B1CaCqkISHNMaTf/JmnfI2rKjRoAI6oTHNlv11If8n/Aixbd 4IURceDrFeoBGzMh56eaQMr1wMSH7mJmp4L/UTDkYz5yB+ICb/dO4R8w7EIRPAvG0cfA I6hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=+aLWTSmeusXkO/h16fvvZMI3E2/PTcSxhwr2HZ0jKu4=; b=KO0op/o9HTbI6og5rrboIE8Tn1G4Ge8UuuBMhI2cEFJCv+fgSkSFpYiPCd1WBxF2QM 8ukjCcdLQmmmn5MQeDINPedVtA+7mk/o6ZQRVTu+4zTHpZ3YZDxTPtPkA+5NNS9E1dC0 ws6RVuOa2xBuyHfkfYle2Bkp00b6vuBzTntqzKFIC1SNRY1m1JL5ZaugGn0mnJzqZuaz fnPYYKUidw7/T/s87Vg/e6fcZgeBwTqsllqH4PNTypsYiX/mbqolkYo8wvJEBxPWdClZ EYJPCPb2I9r1xjauNV0+dVnLD8KOehqfJuHG1+Kx2PiFan8Rb9YBN04Qqm4BbIfjEIag wh4w== X-Gm-Message-State: ABUngveFz1+xUuPbV6BKQ1WnpfoMIQW8RXz///c3XZmYz7sBWq97c4QXKqpq9YUJXgYdX7KQsZYlcuYmEv6z1dM+ X-Received: by 10.36.79.10 with SMTP id c10mr11010313itb.56.1479346682763; Wed, 16 Nov 2016 17:38:02 -0800 (PST) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.201.65 with HTTP; Wed, 16 Nov 2016 17:38:02 -0800 (PST) From: Maxim Sobolev Date: Wed, 16 Nov 2016 17:38:02 -0800 X-Google-Sender-Auth: q0nsRGutbS1VFQsdhtfRwoEzFg8 Message-ID: Subject: Adding variant of SO_TIMESTAMP: bumping so_options from short to int or some other way around? To: freebsd-hackers@freebsd.org, FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:38:03 -0000 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.