From owner-svn-src-head@freebsd.org Sat Nov 19 21:46:14 2016 Return-Path: Delivered-To: svn-src-head@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 97F0AC4B37C; Sat, 19 Nov 2016 21:46:14 +0000 (UTC) (envelope-from imp@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 684EB1A5E; Sat, 19 Nov 2016 21:46:14 +0000 (UTC) (envelope-from imp@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id uAJLkDVo094318; Sat, 19 Nov 2016 21:46:13 GMT (envelope-from imp@FreeBSD.org) Received: (from imp@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id uAJLkDP5094317; Sat, 19 Nov 2016 21:46:13 GMT (envelope-from imp@FreeBSD.org) Message-Id: <201611192146.uAJLkDP5094317@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: imp set sender to imp@FreeBSD.org using -f From: Warner Losh Date: Sat, 19 Nov 2016 21:46:13 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r308869 - head/sbin/nvmecontrol X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 21:46:14 -0000 Author: imp Date: Sat Nov 19 21:46:13 2016 New Revision: 308869 URL: https://svnweb.freebsd.org/changeset/base/308869 Log: i386 turns out to not have __uint128_t. So confusingly use 64-bit math instead. Since we're little endian, we can get away with it. Also, since the counters in quesitons would require billions of iops for tens of billions of seconds to overflow, and since such data rates are unlikely for people using i386 for a while, that's OK. The fastest cards today can't do even a million IOPs. Noticed by: dim@ Sponsored by: Netflix, Inc Modified: head/sbin/nvmecontrol/logpage.c Modified: head/sbin/nvmecontrol/logpage.c ============================================================================== --- head/sbin/nvmecontrol/logpage.c Sat Nov 19 21:10:46 2016 (r308868) +++ head/sbin/nvmecontrol/logpage.c Sat Nov 19 21:46:13 2016 (r308869) @@ -75,10 +75,18 @@ kv_lookup(const struct kv_name *kv, size } /* - * 128-bit integer augments to standard values + * 128-bit integer augments to standard values. On i386 this + * doesn't exist, so we use 64-bit values. The 128-bit counters + * are crazy anyway, since for this purpose, you'd need a + * billion IOPs for billions of seconds to overflow them. + * So, on 32-bit i386, you'll get truncated values. */ #define UINT128_DIG 39 +#ifdef __i386__ +typedef uint64_t uint128_t; +#else typedef __uint128_t uint128_t; +#endif static inline uint128_t to128(void *p)