From owner-freebsd-hackers@freebsd.org Thu Nov 17 01:38:03 2016 Return-Path: Delivered-To: freebsd-hackers@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 8248FC45988 for ; Thu, 17 Nov 2016 01:38:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 55CFBC78 for ; Thu, 17 Nov 2016 01:38:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x22d.google.com with SMTP id j191so9928007ita.1 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=ThJofbkUO3MR2GWXaGMgOxJTgFjKKUkSDkCxOmplmWmBS8DHYf+sOMiVQuBygzfk/z 6OhwdsnR2LN9/Sb2C/8/5p67+s4UoSvATxF1KNcG17Olxb1mtWIRL4iqb3ahp6YNRTD9 mNUeSQVwzkH6cVlL8oSk/kMCUwRd7dJBV1nnvJYSsu+3Ek/AaILuo+tByvpi+GW4W5td zwDcRsesIm1osslgbspM2V0YWumB6AoywQ/huTjIahOHIXVjuMZEzkzRAff43cX7LDjU Hw2qlntmpyVvoSqKCPL5yBfQx3043/DmN+oARR+9qVYgiTp4swzoiKGuX6XK9/HQFVLG n/Sg== X-Gm-Message-State: ABUngvf5Zvd71xH18xaO1nDgSV9iKLCQfxaNf1oACRMM3SEznVLL4TllbBZS4XryRA3qye5+QtC3jy2BEIrHbC90 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-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to 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.