From nobody Mon Feb 9 19:14:39 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f8vWj10p0z6Rsls for ; Mon, 09 Feb 2026 19:14:25 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with SMTP id 4f8vWg2mKqz3GwS for ; Mon, 09 Feb 2026 19:14:23 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=tarsnap.com; spf=pass (mx1.freebsd.org: domain of gperciva@tarsnap.com designates 54.86.246.204 as permitted sender) smtp.mailfrom=gperciva@tarsnap.com Received: (qmail 2351 invoked from network); 9 Feb 2026 19:14:22 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by mail.tarsnap.com with SMTP; 9 Feb 2026 19:14:22 -0000 Date: Mon, 9 Feb 2026 11:14:39 -0800 From: Graham Percival To: freebsd-current@freebsd.org, freebsd-git-weekly@tarsnap.com Cc: Colin Percival Subject: FreeBSD Git Weekly 2026-02-02 to 2026-02-08 Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-3.59 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.90)[-0.896]; DMARC_POLICY_ALLOW(-0.50)[tarsnap.com,none]; R_SPF_ALLOW(-0.20)[+ip4:54.86.246.204/32]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4f8vWg2mKqz3GwS X-Spamd-Bar: --- Hi all, I'm happy to announce FreeBSD git weekly for 2026-02-02 -- 2026-02-08: https://freebsd-git-weekly.tarsnap.net/2026-02-02.html It's a list of the 212 commits in that week, split into categories. Highlighted commits: - daemon: Add option for output file mode "Highlighted" commits are selected automatically if a commit modifies UPDATING, or if the commit message contains a "Relnotes:" line. If you think that another commit should be highlighted, let me know and I'm happy to make it so. To see all reports: https://freebsd-git-weekly.tarsnap.net/ This work is funded by cperciva@ and Tarsnap Backup Inc. Cheers, - Graham Percival From nobody Mon Feb 9 20:49:35 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f8xdZ3lRkz6S0Jx for ; Mon, 09 Feb 2026 20:49:38 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f8xdY32Q2z3XHV; Mon, 09 Feb 2026 20:49:37 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770670178; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=lNmIYWs4pl+EhKe5hdd0v1x+7ms3btQNqfNs26KgYxo=; b=tm9DrTc7RtkQ0Uq4N8ATpbo+Hd5nGehnvMg5tOcikFdybshmXdvlV8pQZ4En/AbRlTLjRN wVNVXyZVIDoMT6uUvrXLnFMBnsU/xdEVqn0yKfXNxamqCQ1Sj5+b9cvo7StGc3zprZgsmS M41Gl+jtlqZssPEPP+lSePOtfkex/ZbTCZvOGUdMINeSoRA9BKQ4BoyxpZFq+m5pNV01Sz hCVJ8w9cxYuqWghTn2YxVP3Ht8J+jDXhZNioQmFksqtqegpio9+rjMscGa7xZa15zdAZeC tVu+M44Wx3WaE4sbLs6jsHred3iA7ZF+7H+2kYbUdUCeqZ2zsKL3ZMs8i8yv4A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770670177; a=rsa-sha256; cv=none; b=RK/8e9hnbSz5OD9kvYySuJmlQRs8EkfL+j+SEBcV70QxyYLMCR+i9kkRGAUoxxetJ4hih5 ubd2KD+FOJ6qfbXv6nDCKy1GkCCMRN9ygFZcW01gYnvsILkYFFu0em5E+RyOJDgdi4GZO7 IMhx/SqLN6AkOtj0gBSHSK/n+yyEPCdYGppda8QXptA35BOXE97P5r8AKiNvEPJ4WBJntC 2sPsOT1ALwJ/R1dVTB97vErjZhB5eCSDDRLmPPAlko7MoPniRBQAgTzMPxjjwZiQVnYZlU 2bwUbW8qRL+pn4aCAi8o4Z3z2iVIpbxwkNyN7bjatqLFOsryuI70Gr+bcHARJw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770670177; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=lNmIYWs4pl+EhKe5hdd0v1x+7ms3btQNqfNs26KgYxo=; b=Ohbb52G0E1GbzkPsL3ahknMAOggVogH9ZxYCbDG1Rosgcg2UEp4sbetgIvWdkL+xAUI3ps Ug72PBL1nef7kVMytlu5pOn41Sqqi4uUwni4gmV7c4931gEb/uAs6iPRtJ8RwXGTfbhnc8 iGmUwJHaXMeA2sRpQsN3v6+LRlVH3VXCkHnbcwkKoBAwoRJX1jc8O4tG7b4nrCM3oFy5Ze pt9HAbAO5NgKu74DRkTWvm/wYvNYUqLhop0KcmjMOHw1BrPictxO+u9/7aFasliZ+zR8nL uesdWrTmt4TlswNfZKECosVINqA6WkWnasPJ3A0eiJuGDIxmCHFe/eXyPYtzTA== Received: from [IPV6:2a01:e11:2002:4280:ab9b:8bf1:ec36:413a] (unknown [IPv6:2a01:e11:2002:4280:ab9b:8bf1:ec36:413a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f8xdX6LrCz5fc; Mon, 09 Feb 2026 20:49:36 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <7521210e-1348-40b8-85ed-8e7a0d3b290a@FreeBSD.org> Date: Mon, 9 Feb 2026 21:49:35 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Guido Falsi Subject: Re: we should enable RFC7217 by default To: Brooks Davis , Pouria Mousavizadeh Tehrani Cc: freebsd-current@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Content-Language: en-US Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/28/26 11:00, Brooks Davis wrote: > On Tue, Jan 27, 2026 at 03:35:16AM +0330, Pouria Mousavizadeh Tehrani wrote: >> Hi everyone, >> >> With `net.inet6.ip6.use_stableaddr` now available, I believe we should enable >> it by default in CURRENT at least. >> As you may already know, we currently use the EUI64 method for generating >> stable IPv6 addresses, which has serious privacy issues. >> >> IMHO, trying to maintain backward compatibility defeats the purpose of a >> privacy RFC. >> >> To be clear, we don't want to change the ip addresses of existing servers. >> However, it's reasonable for users to expect changes during a major upgrade >> (15 -> 16), a fresh install of a new major release, or living on CURRENT. >> So, for obvious reasons, changing the default value would not be MFCed. >> >> What do you think? > > I wonder if we should ship an update to 15 (landing in 15.1) explicitly > adding net.inet6.ip6.use_stableaddr=1 and a suitable comment to > /etc/sysctl.conf so people who later upgrade to 16 aren't painfully > surprised when their server disappears. New installs of 16 would get > the new default, but upgrades would keep the old default. The downside > would be that people who have edited sysctl.conf would have a merge > conflict to resolve, but that's a fairly normal thing. > > -- Brooks > Hi all, I just committed the change in the default (thanks to zlei for approving it, and all the reviewers). [1] I'll also send an heads up to current@ and net@ just in case. I am replying t this specific message in the thread because I do like brooks' idea on how to introduce this on stable. Once I get the MFC approved and committed [2], I could send a further PR implementing such a change on stable/15 sysctl.conf. Thanks all for the support. [1] https://cgit.freebsd.org/src/commit/?id=a2eb0894b79bd0241e51c6888a52bea369ae8a6a [2] https://reviews.freebsd.org/D54382 -- Guido Falsi From nobody Mon Feb 9 21:05:41 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f8y0K3d9vz6QXKb; Mon, 09 Feb 2026 21:05:53 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from vogon.madpilot.net (vogon.madpilot.net [IPv6:2a01:4f8:1c1c:11e5::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4f8y0J44Xgz3bD2; Mon, 09 Feb 2026 21:05:52 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=cyq4qetkgngm header.b=rZGBZ4Uh; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 2a01:4f8:1c1c:11e5::1 as permitted sender) smtp.mailfrom=mad@madpilot.net Received: from localhost (mail [IPv6:fd5c:5351:d272::3]) by vogon.madpilot.net (Postfix) with ESMTP id 4f8y081pMpzLmZw; Mon, 09 Feb 2026 22:05:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:subject :subject:from:from:content-language:date:date:message-id :received; s=cyq4qetkgngm; t=1770671142; x=1772485543; bh=cUutQz 14Jo7RhGx/6YBq8SlCYDSDR6mbSHWytQokMvo=; b=rZGBZ4UhrSDnUJ7K5pstcM MWc0lLLIUhX/ibTB+/KxfaGVtsBeSHQPtshafCU3g9G91GSdLU0M/UBsiuIbbhAp Z71sOjqrmUSPdYAWeDGTKeq9G/g9MsRYOcc5j4HHtvlmhQx3MlC5EwsEBhy01JBw Y3rM9llCM23cxTtqOUJaQ5LbDsitt9ZW77XXP0k0T1BY+xSB48BxXponq4kwZEhp OUURXdsTmVolqk5xROsat4364HEFflZBuiJZxwwhkv8C6L0WQAwKQXW4Ec6rZ//2 O7J2QxqOgNA7cHMMP+0jg6p4Vyxq/aWI95+0zHoWDbOyFSzWexTAAGmrzdwm0YGw == Received: from vogon.madpilot.net ([IPv6:fd5c:5351:d272::3]) by localhost (vogon.madpilot.net [IPv6:fd5c:5351:d272::3]) (amavis, port 10026) with ESMTP id vSrpdFsxDXwp; Mon, 9 Feb 2026 22:05:42 +0100 (CET) Message-ID: Date: Mon, 9 Feb 2026 22:05:41 +0100 To: freebsd-current@freebsd.org, net@FreeBSD.org Content-Language: en-US From: Guido Falsi Subject: HEADS UP: IPv6 SLAAC default algorithm changed (RFC 7217) Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeQQTAQgAIwIbAwIeAQIXgAUL CQgHAwUVCgkICwQWAgMBBQJS79AgAhkBAAoJEBrmhg5Wy9KTc0kH/RO64ORBlTbTHaUaOj8F Je5O5NU2Pt9Cyt5ZWBRvxntr1zPTJGKRPS9ihlIfqT4ZvEngQGp57EUyFbCpI0UWasTerImM tt5WACnGmCzUTB39UXx8Oy4b1EgWeTJQ747e/F1mQLXTNa6ijRBE9fYlTb4gAkPN88/wVV9v 3PZozKLTg16ghBzHM/P7Lk8L7clPEZChX1FTa/6eSt3nvzfCuTMZbBPJF/ph+q1KyPqRgVfh tyhu5dvgMoPz/ni41IfeSrkJTD5RXzdyGR9q4Z1NYeBsLkRjC4LxKAP5KqUsvlOUjKvO1byj ApYdMarol+IGkaSk9e3zVYAJkWKjn/ni8XbOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj6SQY isvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef+WE7 5M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ubeT3Xw QO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr8OEQ fOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB2i6A /xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45qfyh MiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0xpNi UilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWAdlKC NTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanCYrAg +8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNRgow3 kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCkX/qw EVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7FjfrV +dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxAlZ/7 i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+lQMZ 9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8LkQd rQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-2.00 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=cyq4qetkgngm]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; RECEIVED_HELO_LOCALHOST(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,net@FreeBSD.org]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4f8y0J44Xgz3bD2 X-Spamd-Bar: - List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Hi, I just performed the commit at [1]. This switches the recently added "net.inet6.ip6.use_stableaddr" sysctl to on by default, causing all new IPv6 interfaces configured to get SLAAC addresses to not derive their addresses from the MAC address but using an implementation of the algorithm suggested by RFC 7217. This is similar to the defaults on most other operating systems. Such addresses are derived by various information on the system so as to be stable for the single host(OS installation) being attached to the same network, but making it near to impossible to track hosts between networks, or exposing the MAC address. The consequence of this is that hosts configured to use SLAAC addresses on IPv6 interfaces will experience an IP change when upgrading across this change. While I'd suggest to adjust to such a change, considering the privacy implications, if strictly needed the change can be prevented in two ways: - Set the net.inet6.ip6.use_stableaddr sysctl to 0 via loader. This is required since the sysctl needs to be set before any interface are created. - set the "-stableaddr" via sysctl, for example in rc.conf. As a sidenote I plan to MFC the relevant code to stable/15, but keep the default for the sysctl to off there. [1] a2eb0894b79bd0241e51c6888a52bea369ae8a6a -- Guido Falsi From nobody Mon Feb 9 21:09:04 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f8y432tBsz6QX92 for ; Mon, 09 Feb 2026 21:09:07 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f8y432N9Mz3cbV; Mon, 09 Feb 2026 21:09:07 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770671347; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=MAtDIbbwZZ5iQk7U6eSd0Oza6Wz2Ul0uNTBctHyhXME=; b=UmmH8JrmbUbLTmsG51TQRqcDLQ+l9XxYTgjA1b4114pqqwrWKd6gZDG52tLeQ4lZyvQxNJ GBNqLQKkTudcHGeO1GTeF0oMfanzb5GsqUxyBx/WV49iEQx8/EDMUxUFiS9EdjlFAhRW+R EjyquLtsMrojpkyKKRtqZc8spd1VgBK5yKMiGzAtw2A5nsW2sqK4/5YtC4IAiwqFnaEe6N ATRDka4+uW+UqPoexkj/hEIhvqSlBnGJmPi4+YPL5L9VXmlRB6aedo8kSJNqrTTU0kR6Fx OpnwCN4oVxWaviB9Y7Xsio9ytS0ROPuxHYic6y9cxbIUQjPfSSJw4OqSEk3MAw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770671347; a=rsa-sha256; cv=none; b=WinGuw/SmWmjYVNHaOYG4S+HLfUsnhSZo23PDliE/Gdwgs5M/ZgKwhwYa6XkpyBsgvB3wg BMn9xiEEGkCeG1hZxGWRs1b4jIKpoV2iqm/Em5tdJ1biALJqwHID70MttBdKr4mD2gRcaf MQ5y/nRLIrkz7KLhpoFon56mpLVqfJtWg9d9+RNNsBthXKm8JRQUNDWa5qthDSOclAbrll qk59nhUrKhx5u8LFdfhsuGM2dwqs8u2Inzyf/piY6U0UsQYV75An6jnsowqXFzgZ6nf4eW H6cfbzGGxbFfv/bbxmDVBbxBG4MXOM5DRhM9mkDiM8n05f755IUEfcApcpVIww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770671347; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=MAtDIbbwZZ5iQk7U6eSd0Oza6Wz2Ul0uNTBctHyhXME=; b=g/8mbWvKIMuc1KLXaTwlTqRM5ShTweh5hPDn6OOMOW0/0ZsyDzag6+wQzOTR6Ki+KXAQOK x1aRsRpji+vfla0wKzJ9cwhpX9JrERIOvOpp7GSU+3Jvxk9uHkuJqtjaG5v1/CHUMqbIlg ohUs/3xtrFjONtybPfBZpRlY9BGLPmN2HLOpboqak6F9fkpt7NS/9/S6JFkO7XFVAumokQ kWgU0WFVIIXumovoSRBGf4NHqika5BXi2UgzEIzEwm+7MBib1QKXVbpmpdnHtgprGdSd7J YHhL3Od1UycnRoWYaSu/2FK3Tk+pG1OM1G4MAVx+ZMKhTn9vLZ5GKcNUus819w== Received: from [IPV6:2a01:e11:2002:4280:ab9b:8bf1:ec36:413a] (unknown [IPv6:2a01:e11:2002:4280:ab9b:8bf1:ec36:413a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f8y425tl1z6Kt; Mon, 09 Feb 2026 21:09:06 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <2593e290-77ec-41d1-801a-79a6eff3dc93@FreeBSD.org> Date: Mon, 9 Feb 2026 22:09:04 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Guido Falsi Subject: Re: we should enable RFC7217 by default To: Brooks Davis , Pouria Mousavizadeh Tehrani Cc: freebsd-current@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <7521210e-1348-40b8-85ed-8e7a0d3b290a@FreeBSD.org> Content-Language: en-US Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: <7521210e-1348-40b8-85ed-8e7a0d3b290a@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/9/26 21:49, Guido Falsi wrote: > On 1/28/26 11:00, Brooks Davis wrote: >> On Tue, Jan 27, 2026 at 03:35:16AM +0330, Pouria Mousavizadeh Tehrani >> wrote: >>> Hi everyone, >>> >>> With `net.inet6.ip6.use_stableaddr` now available, I believe we >>> should enable >>> it by default in CURRENT at least. >>> As you may already know, we currently use the EUI64 method for >>> generating >>> stable IPv6 addresses, which has serious privacy issues. >>> >>> IMHO, trying to maintain backward compatibility defeats the purpose of a >>> privacy RFC. >>> >>> To be clear, we don't want to change the ip addresses of existing >>> servers. >>> However, it's reasonable for users to expect changes during a major >>> upgrade >>> (15 -> 16), a fresh install of a new major release, or living on >>> CURRENT. >>> So, for obvious reasons, changing the default value would not be MFCed. >>> >>> What do you think? >> >> I wonder if we should ship an update to 15 (landing in 15.1) explicitly >> adding net.inet6.ip6.use_stableaddr=1 and a suitable comment to >> /etc/sysctl.conf so people who later upgrade to 16 aren't painfully >> surprised when their server disappears.  New installs of 16 would get >> the new default, but upgrades would keep the old default.  The downside >> would be that people who have edited sysctl.conf would have a merge >> conflict to resolve, but that's a fairly normal thing. >> >> -- Brooks >> > > > Hi all, I just committed the change in the default (thanks to zlei for > approving it, and all the reviewers). [1] > > > I'll also send an heads up to current@ and net@ just in case. > > > I am replying t this specific message in the thread because I do like > brooks' idea on how to introduce this on stable. > > Once I get the MFC approved and committed [2], I could send a further PR > implementing such a change on stable/15 sysctl.conf. While writing my heads up message I just noticed this plan cannot work, unluckily. Due to the nature of the sysctl, enabling it via /etc/sysctl.conf would cause the change to only affect interfaces created after sourcing the file. This means that for most machines the default interface would be unaffected and keep the default to the in kernel one. To achieve the effect Brooks suggests would require the "soft switch" to happen via loader.conf. Not sure if this is a good idea though. -- Guido Falsi From nobody Mon Feb 9 21:48:50 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f8yxv0kJLz6QbFV for ; Mon, 09 Feb 2026 21:48:51 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f8yxt6wT1z3lYJ; Mon, 09 Feb 2026 21:48:50 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770673731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UKBm0Fzb3IlUIYT5rIWqUZ3vdVcvFAUwNe+l1Uyfp7Q=; b=QolPGAsoYo8TvwtKa+XVa1YuKhLDqG31dAB31rjP7X7kpDVDtoqKubWbR9fVBH8n0t4HvT NbwteTti1NhKoUMBeu+N/gEG6fN6jgWvkAnTtp9wWgPe61lf2s2DxKIAoiUZ9Ire85qoVl JPSECOPqqFEDGZmjlQ32vRt2chdJpL7mBqoyG+/21QAYac3//8FEy2L7pns8/WbP42cAXD 4+NK8eQki7WxDgYheYAt7VmrhUYTAKb7rH+If992L29PoLJmlEzDev800p9CxvYYJvVkJR hKglokdnm6v1Jd68R1glfVg3aicEyQmQ+950qEC/PyOorv0x9v36chNRB83j4Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770673731; a=rsa-sha256; cv=none; b=R2pzq3c3pbKpUmF2OYnp98DgfO7b9TXbOaQd6IW9NU+ucTy3bfQqFdCLcWu7/sUQ3kq8S4 ieCfsnDwZszJe+E/8A6j8BPDqwLRf4uGodWLtv/qVKHj0T3LWPsplxAIsn+Ag+2sDlacVV nI2OOytfdtrss4bYWDkFxJULJjod+3sMPUcz9CEumzorumwE1FqpjjM131WROVlfw5vEhQ ms4ulfm/2bFNQmoSsBy0wmFcyNa6fzy/NstPU6zsz8nKf4okKQYcorIkxXmWn8IJvD+CDX 8pFRzxDHCbGE7L/LMTG3WdmJm1bjbDSwPo4dWPgzI4NdM4906OWeSdOOLQEY8g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770673731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UKBm0Fzb3IlUIYT5rIWqUZ3vdVcvFAUwNe+l1Uyfp7Q=; b=W+QZBtz/2tyfVkl4/dH6EQx3AmQg6g8284KjlLZJ/k3sjqGjqZoEu1xtLobz/t6w/i/wCJ MIk2VChXjRJw9uLhLl918f1/cKnoBa0xHGKd0narAykBg44nSSA/xWEpPQSsOH5I4YcYkQ ZWc0uNVsVLZvOcZwd9aLpMSp6YNowoPToyBM1Qbb6piBqnfNvnE12flj+dsuHb4i/eo4Qn WyUH6p+1jlou6Y21CNgP8m7pLrIBET0R8sM5+Kr/SkPRe/XyM0+jZx3ZL/kbfWvE9eFsXt 1IWUcEO/mQJoXn9PmXzQt43WwgsBIhuAUglXwU/as9IR0Oq9PTDaJsomYQ9+1g== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f8yxt61p1z5mg; Mon, 09 Feb 2026 21:48:50 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 131BB3C01A1; Mon, 09 Feb 2026 21:48:50 +0000 (UTC) Date: Mon, 9 Feb 2026 21:48:50 +0000 From: Brooks Davis To: Guido Falsi Cc: Pouria Mousavizadeh Tehrani , freebsd-current@freebsd.org Subject: Re: we should enable RFC7217 by default Message-ID: References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <7521210e-1348-40b8-85ed-8e7a0d3b290a@FreeBSD.org> <2593e290-77ec-41d1-801a-79a6eff3dc93@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2593e290-77ec-41d1-801a-79a6eff3dc93@FreeBSD.org> On Mon, Feb 09, 2026 at 10:09:04PM +0100, Guido Falsi wrote: > On 2/9/26 21:49, Guido Falsi wrote: > > On 1/28/26 11:00, Brooks Davis wrote: > > > On Tue, Jan 27, 2026 at 03:35:16AM +0330, Pouria Mousavizadeh Tehrani > > > wrote: > > > > Hi everyone, > > > > > > > > With `net.inet6.ip6.use_stableaddr` now available, I believe we > > > > should enable > > > > it by default in CURRENT at least. > > > > As you may already know, we currently use the EUI64 method for > > > > generating > > > > stable IPv6 addresses, which has serious privacy issues. > > > > > > > > IMHO, trying to maintain backward compatibility defeats the purpose of a > > > > privacy RFC. > > > > > > > > To be clear, we don't want to change the ip addresses of existing > > > > servers. > > > > However, it's reasonable for users to expect changes during a > > > > major upgrade > > > > (15 -> 16), a fresh install of a new major release, or living on > > > > CURRENT. > > > > So, for obvious reasons, changing the default value would not be MFCed. > > > > > > > > What do you think? > > > > > > I wonder if we should ship an update to 15 (landing in 15.1) explicitly > > > adding net.inet6.ip6.use_stableaddr=1 and a suitable comment to > > > /etc/sysctl.conf so people who later upgrade to 16 aren't painfully > > > surprised when their server disappears.?? New installs of 16 would get > > > the new default, but upgrades would keep the old default.?? The downside > > > would be that people who have edited sysctl.conf would have a merge > > > conflict to resolve, but that's a fairly normal thing. > > > > > > -- Brooks > > > > > > > > > Hi all, I just committed the change in the default (thanks to zlei for > > approving it, and all the reviewers). [1] > > > > > > I'll also send an heads up to current@ and net@ just in case. > > > > > > I am replying t this specific message in the thread because I do like > > brooks' idea on how to introduce this on stable. > > > > Once I get the MFC approved and committed [2], I could send a further PR > > implementing such a change on stable/15 sysctl.conf. > > While writing my heads up message I just noticed this plan cannot work, > unluckily. > > Due to the nature of the sysctl, enabling it via /etc/sysctl.conf would cause > the change to only affect interfaces created after sourcing the file. This > means that for most machines the default interface would be unaffected and > keep the default to the in kernel one. > > To achieve the effect Brooks suggests would require the "soft switch" to > happen via loader.conf. Not sure if this is a good idea though. I think all my reasoning still applies to loader.conf. IMO, people are going to be really upset if they miss a release note that causes their system to be inaccessable via IP. Even with proper remote access, it's super annoying to fix (having done this to myself many times by many means). -- Brooks From nobody Mon Feb 9 23:21:25 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f910q5hhLz6Qj7H for ; Mon, 09 Feb 2026 23:21:31 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4f910q1lgqz428X; Mon, 09 Feb 2026 23:21:29 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from delta.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 619NLQOY051921; Tue, 10 Feb 2026 08:21:26 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1770679286; bh=QPZUh0/CYrc/HrVvXxdAK2lx8p3CBmP0jqRQY3MCZm4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=JZW534pXR7+nVA+MSSVSAwRqJpWcSaL/PBoL7Huka9gpT8ufpMgmsU1JTB9Su4j+0 D7JWwnqfJW5Grt2k7DJ4DY78WTaPg6oKx1juzj18gr25j+iLrG37gkJWiwdJF7cMG/ 8iWAN/MEfPqNBYW5mbL15I9MNiRyZE5G6c7Ft0F8= Date: Tue, 10 Feb 2026 08:21:25 +0900 From: Tomoaki AOKI To: Brooks Davis Cc: Guido Falsi , Pouria Mousavizadeh Tehrani , freebsd-current@freebsd.org Subject: Re: we should enable RFC7217 by default Message-Id: <20260210082125.dd7bea38970bd9b635655eb4@dec.sakura.ne.jp> In-Reply-To: References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <7521210e-1348-40b8-85ed-8e7a0d3b290a@FreeBSD.org> <2593e290-77ec-41d1-801a-79a6eff3dc93@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4f910q1lgqz428X X-Spamd-Bar: ---- On Mon, 9 Feb 2026 21:48:50 +0000 Brooks Davis wrote: > On Mon, Feb 09, 2026 at 10:09:04PM +0100, Guido Falsi wrote: > > On 2/9/26 21:49, Guido Falsi wrote: > > > On 1/28/26 11:00, Brooks Davis wrote: > > > > On Tue, Jan 27, 2026 at 03:35:16AM +0330, Pouria Mousavizadeh Tehrani > > > > wrote: > > > > > Hi everyone, > > > > > > > > > > With `net.inet6.ip6.use_stableaddr` now available, I believe we > > > > > should enable > > > > > it by default in CURRENT at least. > > > > > As you may already know, we currently use the EUI64 method for > > > > > generating > > > > > stable IPv6 addresses, which has serious privacy issues. > > > > > > > > > > IMHO, trying to maintain backward compatibility defeats the purpose of a > > > > > privacy RFC. > > > > > > > > > > To be clear, we don't want to change the ip addresses of existing > > > > > servers. > > > > > However, it's reasonable for users to expect changes during a > > > > > major upgrade > > > > > (15 -> 16), a fresh install of a new major release, or living on > > > > > CURRENT. > > > > > So, for obvious reasons, changing the default value would not be MFCed. > > > > > > > > > > What do you think? > > > > > > > > I wonder if we should ship an update to 15 (landing in 15.1) explicitly > > > > adding net.inet6.ip6.use_stableaddr=1 and a suitable comment to > > > > /etc/sysctl.conf so people who later upgrade to 16 aren't painfully > > > > surprised when their server disappears.?? New installs of 16 would get > > > > the new default, but upgrades would keep the old default.?? The downside > > > > would be that people who have edited sysctl.conf would have a merge > > > > conflict to resolve, but that's a fairly normal thing. > > > > > > > > -- Brooks > > > > > > > > > > > > > Hi all, I just committed the change in the default (thanks to zlei for > > > approving it, and all the reviewers). [1] > > > > > > > > > I'll also send an heads up to current@ and net@ just in case. > > > > > > > > > I am replying t this specific message in the thread because I do like > > > brooks' idea on how to introduce this on stable. > > > > > > Once I get the MFC approved and committed [2], I could send a further PR > > > implementing such a change on stable/15 sysctl.conf. > > > > While writing my heads up message I just noticed this plan cannot work, > > unluckily. > > > > Due to the nature of the sysctl, enabling it via /etc/sysctl.conf would cause > > the change to only affect interfaces created after sourcing the file. This > > means that for most machines the default interface would be unaffected and > > keep the default to the in kernel one. > > > > To achieve the effect Brooks suggests would require the "soft switch" to > > happen via loader.conf. Not sure if this is a good idea though. > > I think all my reasoning still applies to loader.conf. IMO, people are > going to be really upset if they miss a release note that causes their > system to be inaccessable via IP. Even with proper remote access, it's > super annoying to fix (having done this to myself many times by many > means). > > -- Brooks Looking into the diff, use_stableaddr is defined as CTLFLAG_RWTUN in sys/netinet6/in6_proto.c. So (not tried though, as I cannot obtain RA from my local ISP, thus, not configured for IPv6) /boot/loader.conf should work as it's tunable, too. To avoid race conditions, /boot/loader.conf should be preferred and RELNOTE (and UPDATING, too?) for this should be based on /boot/loader.conf case. Regards. -- Tomoaki AOKI From nobody Tue Feb 10 02:13:59 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f94qz3DLLz6RD5M; Tue, 10 Feb 2026 02:14:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f94qv4PSDz3LWW; Tue, 10 Feb 2026 02:14:03 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770689643; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nPvuzVscdIdtj1Rke3T18ilvzY9sUN4KgwuHuXuXko8=; b=d85n9Ie46NauqPRB1egr7jsc4XT2GW/bq7DvjANqtn7dpGtMtpsFSk3ZZ+8+Z85yJJhtjX klIj36a2haEINC+8d42OxlT7zo/ZcSVZCaj2yfcDCkHr2k1ADKy0IWo99m6XRpjNYcP+5V mt4Kaxa9jdRf2D51xFVdMakMZyO3QkzGee5y36n1T+MBOGVBL/d3OdvYqY/UQlPCD7xNLP JufWuh9hWFAdWhFmCpkNEw1WGJxKFZRevPd9E7c80QRFa5Ly1tJPOMnfFUAkfKLJARRPw8 3b4QXi9lDIY6dX6kAS35j2LBU8UGE2E4SLrJ2z5XKWjYQOlV15/DbilLcFVdpg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770689643; a=rsa-sha256; cv=none; b=af0+ysrOjE7zRUkQmu5i6d0vNj+EBqHqmeud8xCjT9305dfKhJhUgHLopsUbWn0f7JuTVz r33H7y4B87wandjQU/8S7nt/Lab2husgYQR+n7om7icbERMp1DERMOOTwEqqgPJy97aoW4 gSkVr18LOetROW60ZmYj4wjIMPqCAE97dXnN9pwn71utCJ1mLIDtJvHycD8y9h+sdyq5Ky ieKvoYJXrJPWt0g1SI6ErIxCi6OpNYirfC9HS0MidN+qReQbKNApAunhJpZ+3xnngS7ASP 3KKe/d/SjVtNCu23Vy84YKKKkDvtShn2BRKJzgycR1rswDFl7TKtGrSCMOvpEg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770689643; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nPvuzVscdIdtj1Rke3T18ilvzY9sUN4KgwuHuXuXko8=; b=l8ulCod2jy5LDrJb7Yr2RQLwk1ZFJLdlbSxv5soDMH9dyILTgxEUrPIFbrvJ7+phqEmMud s+OWXg3vMoipw3SKIhZYHiIK1UWE8IWQ/pv8ObIq5DMWiN8o+2dsh0nJ7gxsfLGPv1dnFI d10Ioyji6Ge/4U8azAFRSRU3SxIWC9ih/3K3fWvQFeS4Zjiuq36gsTNi2fv6RrQ1oedfuE CR2YE8wFUwzQeCPgqQJSOncnBisJdDWkZ6Mmpyuf8Wcj2bXCnjN4RY2Xr9lQ2M+1j1TZZF YaY9SGeqhp49lLrxHynHupbCSFDpLfeb2Zv4LOJdBaJ68QBlyVjzoCJRYWwKxw== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E8" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f94qv2pNwzCTp; Tue, 10 Feb 2026 02:14:03 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id DA63FA64805; Tue, 10 Feb 2026 02:13:43 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A8D372D029E7; Tue, 10 Feb 2026 02:14:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id QYwySBznIDg7; Tue, 10 Feb 2026 02:14:01 +0000 (UTC) Received: from nv.t4-02.sbone.de (nv.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id F31042D029D8; Tue, 10 Feb 2026 02:14:00 +0000 (UTC) Date: Tue, 10 Feb 2026 02:13:59 +0000 (UTC) From: "Bjoern A. Zeeb" To: usb@freebsd.org, current@freebsd.org, stable@freebsd.org Subject: Re: Is any code using LinuxKPI USB? In-Reply-To: <3r088246-07r5-q2s2-8149-270n240q3r61@SerrOFQ.bet> Message-ID: <417851n7-1r6r-p035-o5ps-8651r2519363@mnoonqbm.arg> References: <3r088246-07r5-q2s2-8149-270n240q3r61@SerrOFQ.bet> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed On Thu, 29 May 2025, Bjoern A. Zeeb wrote: Hi, > I have a year old work in progress which breaks the decade-ish old > LinuxKPI USB support. I am trying to find out if there is anything > actually (still) using this code? If you know of any program/code which > relies on LinuxKPI USB then please let me know ASAP. I figured I am going to give it another last try as by now a lot more LinuxKPI USB has become real. The only comment I had gotten was about webcamd and that is, to my best understanding, a pure user space implementation (of the LunuxKPI) using libusb20 as the underlying framework. /bz -- Bjoern A. Zeeb r15:7 From nobody Tue Feb 10 15:23:34 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f9QMB3Nchz6RTqJ for ; Tue, 10 Feb 2026 15:23:50 +0000 (UTC) (envelope-from bugsbeastie@gmail.com) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f9QM92tNDz44xC for ; Tue, 10 Feb 2026 15:23:49 +0000 (UTC) (envelope-from bugsbeastie@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=gs5LZP8G; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bugsbeastie@gmail.com designates 2a00:1450:4864:20::32b as permitted sender) smtp.mailfrom=bugsbeastie@gmail.com Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47edd9024b1so53942215e9.3 for ; Tue, 10 Feb 2026 07:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770737022; x=1771341822; darn=freebsd.org; h=content-transfer-encoding:mime-version:subject:message-id:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=FPWG2MJwP9kUjWWRe/ThY3cVMUdg9OlZZGnDC57vkLM=; b=gs5LZP8GOdaTGgkGIc9X/cgATAMNDthSTKZU+23diq6ftHkLmZPiCiojjMGIlpLPEH 0r9g3/fGcVkWHFaRG0CqsO1MsZjiIw+ocmm3I2UhsL2DsVtzEfOr3KELyxkY7HV4kEKp /QoNa8mD1wQ9HqnOCyB9QIlLUYcrSUOZo7lvoHc6MqEMPIIBiDN189wIRTvxz/Hkg1/4 OygKiu1gGxk8PX8W5cg7qKB8Qh5HAxcu9dwpX5X/8fYushplLhPb3IEPctyE6RnOM0CW xS+u5TjQWvEGD+iRLDuaNg4NDUrVGfn9UWD1u7VlGjp5HfG4ZJuPmLblx1Iq0FhEXvYq ydog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770737022; x=1771341822; h=content-transfer-encoding:mime-version:subject:message-id:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FPWG2MJwP9kUjWWRe/ThY3cVMUdg9OlZZGnDC57vkLM=; b=ZL0PVxEgvxM7bHpTcgZdf4Ovlsl0S6e47NhPSvxDWEDnKa6YvuU8KlKUuPGyWvfNU/ thp0Bt7uGwz8GYx4axPeu9QPBZA0vJSjZlCrmjEnEV4p+8p9rL3Cxn5sodPaqiXznK98 xP3WL2EKGxnZ5VwWSF2ECiZqg8QWhR/Kd1jbQ3dMsB0jf/DrIOHD2jAGn/fDJM2SLEXR 7wO6T1UTme3etq/ga7LNNSMGNpnMHkR7dySBq/0zfCeZmewdlyu1vduY5JbK88Emxk47 PVov1z7yP1kumR3nX24EQk7TQd+KXjafktCrZvjpt4nmYWvSBlXOjlR/mGCLCMfV+pEE G/Tg== X-Gm-Message-State: AOJu0YwIh7LlvwyJLbqLnSCQRwyLWmfMluafsfiwHQvE+/G7ggwFv8hf 4mTCktzW4ZeO12norMsCG8CObk33oMbUuQupuYZUqnMvh1aqE3aIkzXaHide1A== X-Gm-Gg: AZuq6aLE9Uh/XcyFm7GgUP6aJ/ta3Fay6lJEOVRwG9jdRLZJ1GENs2I2rAB/fRGJoU2 Z1tQg3BjJ4vzHa0e2mfc/jImLAJiWx23G2SknKRMQMBnDw4bCn3rgLNgr5CSEKyksUcu90Tpy37 FE7oleRmFXLoYPimz7N1CxNSQutvYoopLZLAP3XnwFmBQUYP/yUT9rkCZva1EKkJh/BQPsHu7vp vfRCyGKWGOtTcpaOw/Z2lbfSIGapVOWrowntlBNYWvkYU0j+HwFoDamll22mXtX6Crl+WqGQhI3 u4sEgWasitvJHl1i9lneTZtNX6Fwv8tw0HWsWdQjPq9wuX0KaSMy4Vm4Oe7kNaKY0W7lDp60wKM DyRXKhLq2uluoCU7pNiI4gq6KEBEw8OactPMzRLwwT6UpU/wxRzkAYVThjmA6fhhi2+Q6W42FW5 EeX+07HJldT1yE3Y1dx0fH0RXuvpg6C7I5rL2uXLZ3z+zU82gJ6bP3x/6v2YGZZJQAuA== X-Received: by 2002:a05:600c:34d1:b0:477:561f:6fc8 with SMTP id 5b1f17b1804b1-483201d9f9bmr208210515e9.5.1770737022368; Tue, 10 Feb 2026 07:23:42 -0800 (PST) Received: from [127.0.0.1] (089144216177.atnat0025.highway.a1.net. [89.144.216.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483203e126dsm230568545e9.2.2026.02.10.07.23.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Feb 2026 07:23:41 -0800 (PST) Date: Tue, 10 Feb 2026 16:23:34 +0100 From: Bugs Beastie To: freebsd-current@freebsd.org Message-ID: <01ead14d-c9e7-455f-aa23-a31769221767@gmail.com> Subject: Using ccache on CURRENT List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Correlation-ID: <01ead14d-c9e7-455f-aa23-a31769221767@gmail.com> X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.942]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RECEIVED_HELO_LOCALHOST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32b:from] X-Rspamd-Queue-Id: 4f9QM92tNDz44xC X-Spamd-Bar: --- Hi fellow CURRENT users! I am trying to follow CURRENT on the desktop system. My typical upgrade path is to update base and then ports/packages. Having monsters like ungoogled-chromium, signal-desktop built upon electron, and libreoffice results in the build times around one week! %) I have tried to plug ccache in, but it seems not to help much! My understanding is that ccache uses hashes of both the sources AND the compilers to store the results. If I recompile the base system each upgrade, the old hashes are gone! Do I understand it correctly? Are there any tricks around to still get ccache working? Something like activating reproducible builds in base (and ports)? The actual changes of both system and port compilers are not that often! Thank you in advance, Alexey From nobody Tue Feb 10 18:45:26 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f9VrF3Dlqz6Rmss; Tue, 10 Feb 2026 18:45:49 +0000 (UTC) (envelope-from gallatin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f9VrF2j78z422B; Tue, 10 Feb 2026 18:45:49 +0000 (UTC) (envelope-from gallatin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770749149; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=N/bMwz2RhM7QHvBhmBD9p9Vjn3gaPpTI/BoLvvA4178=; b=eq0ifxftPJ5eUN4s3reU5ALfC2lluEPyXeDU6BZSp5EyLXvUs5ViFugUpazhuoXUPdeKdW /YV8s7zvbPoZ6mFecp/CrKjU/urAyumyDqlr05to4lMiYN1yKj0Mdq1ts8pc1nivKkKVpJ fZfNrtFxn6/EU9mo8s8eJKowag5M/CJRpuLhJDQYvK7Gk/lGIqEl3f7O62zmO1tW4wDVFQ NiulSkUgZW91ZKW9nhhdrvUDQHr5cJtHJUn59aREUeQWaoGxRnZjCKAFfepa7lZpEWbux/ FVNwp6E2rW88TmCAhWwurmV27rhcSH5xa3x1d1CqQaGXcdkPFP8vitJM8RmQfA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770749149; a=rsa-sha256; cv=none; b=A4oRw4hAJe03/q5OUBj+HyHzTFaquMO+DbtcShT9UqPsVVHhpYhTGkMEDHWAQ2Aog3KUfC zhLt9dLf5YkBRMsA0Lbr+6qfYu29+hAPG5cUj+VmpNQVbP+pKgfAIH75uSulN/DdLq3MCq jEuFLqXlp15D57uNCBPgF9uGqi5KFyoyTjEEJ8/QFG2pvNJoqIqGTKcVbC/B/OLhyYihZ5 f9dDEjJuc5UGDzYfIfwQznU2zXqa96PwCqGm3T8y4CB2kljjHf7pkmMa2YD11aRcqdsBV4 ZY0nfNi4cv13sdkYhuTVay2uWrLlIjRL5BUYjHzJPXrzEscF6jJd07aCP1X1Wg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770749149; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=N/bMwz2RhM7QHvBhmBD9p9Vjn3gaPpTI/BoLvvA4178=; b=oT2xjBpEeHKuemf8ur7FiLCLZHcYs/v7WIz0jnhkl8teg/QcBxP05q8uoNXHuUMuHk4zRm fD/J+LDLiJuLQy8G4BzycWiz85oyTk+QSNaZV+XxXI23lsOs7APmNWVPUHG5lyFs23mYC7 KWBOv5qkn3Ea5GM620g2FOwfDju8AGjmhieFk2vqIjHCHsGJOk8iYCb/BtVj+fmBwCExug I9S9YKTKV2nl7bPHLkV+mJ6ukub29shNebPcwFtWExgDKgwPtkLT880VrN+KX8H8rYNznX gOTxvI3sjQbhj/sm1CoD4+pynBbzOap6Z5Fat6NvnYtIgYAs4lTyWLTVyPPKsQ== Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com [103.168.172.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gallatin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f9VrF17Q2zp3M; Tue, 10 Feb 2026 18:45:49 +0000 (UTC) (envelope-from gallatin@freebsd.org) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id F33B7F4006C; Tue, 10 Feb 2026 13:45:47 -0500 (EST) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-05.internal (MEProxy); Tue, 10 Feb 2026 13:45:47 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvtddtgeefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgesrgdtreerredttdenucfhrhhomhepfdffrhgvficu ifgrlhhlrghtihhnfdcuoehgrghllhgrthhinhesfhhrvggvsghsugdrohhrgheqnecugg ftrfgrthhtvghrnhepieejveffieejiedukeejffejfefhlefgudfgteelteekueduheev ffevfedvleevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepghgrlhhlrghtihhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddu feefheelvddvudeiqddvleehtdegudekgedqghgrlhhlrghtihhnpeepfhhrvggvsghsug drohhrghesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopegrohhksghlrghsthesfhhrvggvsghsugdrohhrgh dprhgtphhtthhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrhgvvggsshgurdhorhhg pdhrtghpthhtohepghhlvggsihhushesfhhrvggvsghsugdrohhrghdprhgtphhtthhope holhgtvgesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehsrhgtqdgtohhmmhhithht vghrshesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i41414658:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id A5ABC700065; Tue, 10 Feb 2026 13:45:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 X-ThreadId: AQpxQpBrI0Yc Date: Tue, 10 Feb 2026 13:45:26 -0500 From: "Drew Gallatin" To: "Olivier Certner" , "Gleb Smirnoff" Cc: freebsd-current@freebsd.org, src-committers@freebsd.org, "ShengYi Hung" Message-Id: <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> In-Reply-To: <8518827.G18vQ0XA4d@ravel> References: <2329920.sMrx5ctUpN@ravel> <6197e075-212f-4260-b437-902e06d1002b@app.fastmail.com> <8518827.G18vQ0XA4d@ravel> Subject: Re: January 2026 stabilization week Content-Type: multipart/alternative; boundary=351c5c71c81845cfb278a5adbd237b71 --351c5c71c81845cfb278a5adbd237b71 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, Jan 29, 2026, at 4:09 PM, Olivier Certner wrote: > > On Intel, and now on AMD, it seems that CPPC is far worse than powerd (*). > > That must depend on workloads and objectives then, since I've had the opposite experience on laptops in terms of latency. > > > (...) And high settings use more power. > > But providing better performance, or not? The same, not better. But statically setting cppc tunables so the performance is as good as powerd's performance means far more power is consumed when we are close to idle. > > So the ability to let software control frequency is something that I don't want to loose. > > I certainly don't have plans to remove that. When talking about recommending CPPC, I was thinking about the default value we wanted to have for the new 'machdep.hwpstate_amd_cppc_enable' tunable, but not about removing it. IMO, this tunable is here to stay (it might just change form at some point). > > I also encourage you to give a shot at the patch in PR 292615, in order to see how the new knobs (min & max performance, desired performance) can affect your observations, even if after what you reported that may look unlikely. > > For the future, we should probably eye at teaching powerd(8) about working with CPPC, so that instead of trying to set frequencies directly (which cannot really work with and basically defeats the point of CPPC) it would instead tune the desired performance value (and possibly the min and max ones as well). Perhaps with that combination we could get the best of both worlds (software + hardware tuning), at least for some workloads. In reading some of the docs for this, I got the impression that CPPC can basically be 2 things 1) A hardware controlled power governor, like our powerd or Linux's frequency governors. 2) A way to expose far more control over CPU frequency than pstates give us (especially on AMD, where pstates generally only give 3 freqs) I'm not at all interested in (1), as I think powerd or something like it does a far better job at trading off power and performance then CPPC on both Xeon and EPYC. However, I think (2) would let powerd do a far better job and I'd be very interested in getting CPPC to optionally expose more frequencies and not do any automatic governing. Drew --351c5c71c81845cfb278a5adbd237b71 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Thu, Jan 29, 2026, at 4:09 PM, Olivier Certner wrot= e:
> On Inte= l, and now on AMD, it seems that CPPC is far worse than powerd (*).

That must depend on workloads and objectives then, = since I've had the opposite experience on laptops in terms of latency.

> (...) And high settings use more power.

But providing better performance, or not?

The same, not better.  But statically= setting cppc tunables so the performance is as good as powerd's perform= ance means far more power is consumed when we are close to idle.

> So= the ability to let software control frequency is something that I don't= want to loose.

I certainly don't have plans to= remove that.  When talking about recommending CPPC, I was thinking= about the default value we wanted to have for the new 'machdep.hwpstate_amd_cppc_enable' tunable, but n= ot about removing it.  IMO, this tunable is here to stay (it might = just change form at some point).

I also encoura= ge you to give a shot at the patch in PR 292615, in order to see how the= new knobs (min & max performance, desired performance) can affect y= our observations, even if after what you reported that may look unlikely= .

For the future, we should probably eye at tea= ching powerd(8) about working with CPPC, so that instead of trying to se= t frequencies directly (which cannot really work with and basically defe= ats the point of CPPC) it would instead tune the desired performance val= ue (and possibly the min and max ones as well).  Perhaps with that = combination we could get the best of both worlds (software + hardware tu= ning), at least for some workloads.

In reading some of the docs for this, I got the impression that CP= PC can basically be 2 things

1) A hardware cont= rolled power governor, like our powerd or Linux's frequency governors.
2) A way to expose far more control over CPU frequency than pst= ates give us (especially on AMD, where pstates generally only give 3 fre= qs)

I'm not at all interested in (1), as I thin= k powerd or something like it does a far better job at trading off power= and performance then CPPC on both Xeon and EPYC.   However, I= think (2) would let powerd do a far better job and I'd be very interest= ed in getting CPPC to optionally expose more frequencies and not do any = automatic governing.

Drew
--351c5c71c81845cfb278a5adbd237b71-- From nobody Tue Feb 10 18:47:28 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f9VtS6Y6sz6RnJG for ; Tue, 10 Feb 2026 18:47:44 +0000 (UTC) (envelope-from jonte.puide@gmail.com) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f9VtS4dYLz43Td for ; Tue, 10 Feb 2026 18:47:44 +0000 (UTC) (envelope-from jonte.puide@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-674181e5bb9so65008eaf.3 for ; Tue, 10 Feb 2026 10:47:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770749259; cv=none; d=google.com; s=arc-20240605; b=PyvMJSovlDkXRdI+y2QnNoKJR0WcMOVn5x+9YBL+Y6yZLskQ9YjOS/ywe2UOpEHiYK YTHw3Y3RkKi4KOqg6E0sdBkpY2UIOSVZiB0VkpArB6J+AZgFtIxqSR0LEr3Cfrg0gHVY hEW/8A7i5EePPDsI8JKfKcrcfzBHS2mt0CercSUSTXW0WLPoMTr29ppld8kN2VchLKT3 BNMb64gTUWY9AZAP/BCAaU9mxv5H4cXbdrZfRn5qXVAgBqBzasQZvc41EaPF3aUmIQwp OchJV6ofp9DSWUDyITMXGdLtyCvBOIFx/OwXs55ZwBHvSox2Dp86snlvuSCo3hAwwzhV 5QVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=8NaK5DMfg06usNOFAHF+3zGDBDVs1rGV+E3o6//1Z0w=; fh=EMG7PWiCOTWMgB23WOUsaHBr7NvXmSQsctpJg8ZVxss=; b=E0/q192Wtff0GUMGEhjhW6+2UPBtYqKtNfB0TEf5NapegWNP+LxL+ipGePzzJo8aFV HrCbwL97Va4YQuL77b9gI53MDk+gp1P6VbPTRt3LiHwKncdIHZ8WP3z34xQO6bjY4P3R 8ythrrZqGukLEPcJ1tC19gvmu+ZEqCqf5cyTxbQbbIZx7RjHxaUsA1BuYsERpH8VDFaM lRWMP9J/zDVnZiehYAEkW8FSWprBrisecN0QG4pcl1kIZeMF9+9myNImcZUcfsJeCg81 fn1NbZda2Stek1WvtW6+ZzkyUIs4sTONHa5Y9vSKvdOu9y0Vu/fBO+JfeiTSX7MgK/qD eQCg==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770749259; x=1771354059; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8NaK5DMfg06usNOFAHF+3zGDBDVs1rGV+E3o6//1Z0w=; b=YQOZ3JDZ2Ljil2ImisPIxrzuTsJyKJ9GyBNyYkQUmloODQ1tHw7+Og4ExfZUb+0Mrv nyvSCke0wwk1ClPeIHe3zFW3Wh5OWwgPY6CDu+LjV6fyoUjtL2I15j97BxA/sV0oFXbz 2eA3770Aadkmh8dggEXtxYVylUZ8JpK98HyhYPIauMee9y/bGOAqKjgYilmO0rHSU4R+ 5NVo5O+w2HJ2oHLVMqtlBF7hJQ5MEyC4Y044VLljpQ8BhEJo46k9lkpurXzA3JJhe3ok HlV0QFq3Vlb8C3sQQ21VDuuURR4ctT+8aUpk1pGrN4ZTGzqjJJ2ZfiP5C120a+4u6zLJ 5tEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770749259; x=1771354059; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8NaK5DMfg06usNOFAHF+3zGDBDVs1rGV+E3o6//1Z0w=; b=Nj/5l+ssPvpElnU7Lhz0/UGXEVz4luY5Qt+cgy9RyM+CF58kRo7GeR6QN29HSl5fZF AcmIBcC1XUWk5YajH0VZM03DDHM2/OgpVM/iUwHHm6M7ywX+uVD57kNgTXtUB9Mp/d3u WcM2/azunFsdxzOhEwlozHXslveWdUlgSAKtz/cItA431aSzcfq1eCgECrxCjYS+UHfF x4mjZU7qkejQgoPVEM2tWsY0pL9+UOBsqx9m/CAtzfrsSaCZUYBJ5IJiAf/G5U1GUew4 sj2Rd4odxl+eWqEwCtontnY/Gki0SNWV+95rWwNV452DSHsCWR3GKYBpeKaDrqaSpEnZ /xNw== X-Forwarded-Encrypted: i=1; AJvYcCWk+y4Sidcxz7eQ/NUv/T4jIAPRXpksGoX85/buWs2+cqju7oBP7q8I1Cvpu6+/myuf0VgprbjSRZIhWIQ7cRA=@freebsd.org X-Gm-Message-State: AOJu0YwccONd/cjIFXNvqpCGVvgvonhYpp/ST7dYWiaf9YWDSbosJ4ml +z5lny4BeNUCeXXrQAv2pGLzdjmj2o+d4inaoVIS9e73in9MVoQ6iJfNHsS3D77nLe/5Nz2m5DP T4Z9ZRlKfCEoh8mlit+qfVQt8i3D8Kbhoy0iP X-Gm-Gg: AZuq6aK+DGuzy+Bzejsn0b5lowWV9kmC17SalmNV85e8xk5NZjqPvdQ6ebosfQM8jL4 A22ZeGVNLevfUckm6ZwVhHW/DCfxH583Vv3uH1HxBrz08kjG96X6DF6tC8yv9Q4XO1lMkE0PdsR aiTDhMU177dLgC+FkcvQwMMuo+14kP1USqZy5Gjkwyu9IDtmQdexcP9jp5FDiVg+D7ubdUwVWPW xCuMcbUtQi6nS8p9YlSPgzEWlgz1cAMgqDAKQGDQPn+368OF0wxXJ4drpksKVuzdGycHyz9EHBT fiS3g3L0gq0zuCM/dzUejBRdeDh+furigfm0HRb7Sh44Vnqu4JA= X-Received: by 2002:a05:6820:4813:b0:66a:9d34:6cc0 with SMTP id 006d021491bc7-6743b4bac35mr7687eaf.27.1770749258666; Tue, 10 Feb 2026 10:47:38 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <2329920.sMrx5ctUpN@ravel> <6197e075-212f-4260-b437-902e06d1002b@app.fastmail.com> <8518827.G18vQ0XA4d@ravel> <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> In-Reply-To: <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> From: Jonathan Puide Date: Tue, 10 Feb 2026 19:47:28 +0100 X-Gm-Features: AZwV_QjAoEmQE6V0kLvHFOGtUv1lRJcz7vpR-YfiMPdEshsQVGaQXmIfyYgjZas Message-ID: Subject: Re: January 2026 stabilization week To: Drew Gallatin Cc: Olivier Certner , Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org, ShengYi Hung Content-Type: multipart/alternative; boundary="0000000000008c97ad064a7cb0af" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4f9VtS4dYLz43Td X-Spamd-Bar: ---- --0000000000008c97ad064a7cb0af Content-Type: text/plain; charset="UTF-8" On my system, powerd functions just fine. Powerdxx too. Maybe it's just my system though. I feel like powerd and powerdxx really does the job well. T, 10. veebruar 2026, 19:45 Drew Gallatin kirjutas: > > > On Thu, Jan 29, 2026, at 4:09 PM, Olivier Certner wrote: > > > On Intel, and now on AMD, it seems that CPPC is far worse than powerd > (*). > > That must depend on workloads and objectives then, since I've had the > opposite experience on laptops in terms of latency. > > > (...) And high settings use more power. > > But providing better performance, or not? > > > The same, not better. But statically setting cppc tunables so the > performance is as good as powerd's performance means far more power is > consumed when we are close to idle. > > > So the ability to let software control frequency is something that I > don't want to loose. > > I certainly don't have plans to remove that. When talking about > recommending CPPC, I was thinking about the default value we wanted to have > for the new 'machdep.hwpstate_amd_cppc_enable' tunable, but not about > removing it. IMO, this tunable is here to stay (it might just change form > at some point). > > I also encourage you to give a shot at the patch in PR 292615, in order to > see how the new knobs (min & max performance, desired performance) can > affect your observations, even if after what you reported that may look > unlikely. > > For the future, we should probably eye at teaching powerd(8) about working > with CPPC, so that instead of trying to set frequencies directly (which > cannot really work with and basically defeats the point of CPPC) it would > instead tune the desired performance value (and possibly the min and max > ones as well). Perhaps with that combination we could get the best of both > worlds (software + hardware tuning), at least for some workloads. > > > In reading some of the docs for this, I got the impression that CPPC can > basically be 2 things > > 1) A hardware controlled power governor, like our powerd or Linux's > frequency governors. > 2) A way to expose far more control over CPU frequency than pstates give > us (especially on AMD, where pstates generally only give 3 freqs) > > I'm not at all interested in (1), as I think powerd or something like it > does a far better job at trading off power and performance then CPPC on > both Xeon and EPYC. However, I think (2) would let powerd do a far better > job and I'd be very interested in getting CPPC to optionally expose more > frequencies and not do any automatic governing. > > Drew > --0000000000008c97ad064a7cb0af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On my system, powerd functions just fine. Powerdxx too. M= aybe it's just my system though. I feel like powerd and powerdxx really= does the job well.

T, 10. veebruar 2026, 19:45 Drew G= allatin <gallatin@freebsd.org> kirjutas:

On Thu, Jan 29, 2026, at 4:09 PM, Olivier Certn= er wrote:
> On Intel, and now on AMD, it seems that CPPC is far worse than powe= rd (*).

That must depend on workloads and objectiv= es then, since I've had the opposite experience on laptops in terms of = latency.

> (...) And high settings use more pow= er.

But providing better performance, or not?



I certainly don't have= plans to remove that.=C2=A0 When talking about recommending CPPC, I was th= inking about the default value we wanted to have for the new 'machdep.h= wpstate_amd_cppc_enable' tunable, but not about removing it.=C2=A0 = IMO, this tunable is here to stay (it might just change form at some point)= .

I also encourage you to give a shot at the patch= in PR 292615, in order to see how the new knobs (min & max performance= , desired performance) can affect your observations, even if after what you= reported that may look unlikely.

For the future, = we should probably eye at teaching powerd(8) about working with CPPC, so th= at instead of trying to set frequencies directly (which cannot really work = with and basically defeats the point of CPPC) it would instead tune the des= ired performance value (and possibly the min and max ones as well).=C2=A0 P= erhaps with that combination we could get the best of both worlds (software= + hardware tuning), at least for some workloads.

In reading some of the docs for this, I got the impression= that CPPC can basically be 2 things

1) A hardware= controlled power governor, like our powerd or Linux's frequency govern= ors.
2) A way to expose far more control over CPU frequency than = pstates give us (especially on AMD, where pstates generally only give 3 fre= qs)

I'm not at all interested in (1), as I thi= nk powerd or something like it does a far better job at trading off power a= nd performance then CPPC on both Xeon and EPYC.=C2=A0 =C2=A0However, I thin= k (2) would let powerd do a far better job and I'd be very interested i= n getting CPPC to optionally expose more frequencies and not do any automat= ic governing.

Drew
--0000000000008c97ad064a7cb0af-- From nobody Tue Feb 10 20:21:11 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f9XyW6cQtz6RyD2; Tue, 10 Feb 2026 20:21:23 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f9XyW5rJfz4Q6h; Tue, 10 Feb 2026 20:21:23 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770754883; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U6lmwbIMCaVhEfaxJpMKFLgfK18qmAlLl7Ze+2yR5gg=; b=wx7RPwbPZI/PoND5FsLTxbjgkwGrETd/m7jEZA3XnDjBb1DcGaa8+q3s1KWPD7M6O1SHlJ RgpFKvbn/wdUbTalWlmkCGjaK7CgyXdUc3mxDCVTdNj6r2ZC7KQP354krwOAktDGaQpX4d DllIe7fbPLqFeuk75BAqeggTb1J8Je+p9l9RPp6TxK7KDJijV3d16SgC4bqkFsRLd7ydom 1ZcXQJf1fAiHR8VclbOn2FTxyWd29SLda50ElSay5+hUAhk8d3PHOQLeID3WN8Q5sOgdBb ze9WJW3XOyu5E+/Wf4/KT6aYh5+tPRX6UWDCyGLtvSupFZIITLNQnH1Tc5uFSQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770754883; a=rsa-sha256; cv=none; b=EogxlrGITTht9nY8uhZscH3/iY8GccyaG2H+qJSBI9X1UClDJ92kGyEV6mJdNgs7UdznW9 4l38b5pfiNhcoDxLX3xn0jwohQmM5pQRtuBbIDcJqDrp7oWHE37w0cXzF7xKjzxKYjeDBu EkbKrUsHlAM/7z6Koy40G4QlnFlyXr0ENoS/kZGxAC6hCWkuad5P72N4865dIX1Cd47KUW g3qUkm1DsL7m7yT+Dml2d8Y+IEwlro0yI0CIdVcOmXIuQwr303sHItA9NfSHHauSSA4vfk lT8MSEb61H3Ccwsj/+dpMlzw6sWSdK+v0CLAydD9aHg5fy7hEgGlv7SZBZTzBw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770754883; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U6lmwbIMCaVhEfaxJpMKFLgfK18qmAlLl7Ze+2yR5gg=; b=ugB6pJxp2BP+d6JFHmTnPbSTetNCzAF4maVa1WOKvpsrcsUN0CCV9kg5/medzdmPN2cub5 FE4FuCM2QsBDudOKd/rzLfmDgYKqQAm3KEXveY/3Idf5s/CwloygUg1woiforVtv2YbP9b PQ9d9cx+PshSjvaPB8+SqLf1q7i8GxeHLImxHSYm4CwpzlRR9L/oHk1j2aYibiHXGwDTZF QO2ovpU4jP2LFiNsQY5014xh0hfs7fI+mkplVDnfZOJf1xJROnpkdJGKzpl//nOQCZ9ud2 4sUK0BNGiV3OReDZzBxxpEl0d45RP0VfKeFsFPgjUwi1Ac58iXqRnf/LCDeHwQ== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f9XyW0xMmzs5l; Tue, 10 Feb 2026 20:21:23 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Gleb Smirnoff , Drew Gallatin Cc: freebsd-current@freebsd.org, src-committers@freebsd.org, ShengYi Hung Subject: Re: January 2026 stabilization week Date: Tue, 10 Feb 2026 21:21:11 +0100 Message-ID: <5959565.bE498FI5Hg@ravel> In-Reply-To: <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> References: <8518827.G18vQ0XA4d@ravel> <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4304977.aWEtfRnraa"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart4304977.aWEtfRnraa Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner Subject: Re: January 2026 stabilization week Date: Tue, 10 Feb 2026 21:21:11 +0100 Message-ID: <5959565.bE498FI5Hg@ravel> In-Reply-To: <7db87f3a-0106-42e1-a71a-34f4bc1c4a26@app.fastmail.com> MIME-Version: 1.0 > In reading some of the docs for this, I got the impression that CPPC can = basically be 2 things >=20 > 1) A hardware controlled power governor, like our powerd or Linux's frequ= ency governors. > 2) A way to expose far more control over CPU frequency than pstates give = us (especially on AMD, where pstates generally only give 3 freqs) That's essentially that, yes. Point 1) is optional. Part of it is implemented by the so-called "autonomo= us mode". On both AMD and Intel, you have to set the desired performance t= o 0 to enable this mode. Any other value disables it. In autonomous mode,= you can use the EPP (Energy/Performance Preference) byte value to hint at = wanting more performance (towards 0) or more efficiency (towards 255). The= requested minimum and maximum performance (see next paragraph) may still h= ave an effect. Point 2) can give you more fine-grained control over power (performance, co= nsumption). First, you have to stop thinking in terms of frequency, switch= ing instead to abstract numerical performance levels. A level is a number = between 0 and 255, so you have at most 256 settings (in fact, 255 for the d= esired performance value, as value 0 is reserved for autonomous mode as sai= d above). The number of them that are really different is however hardware= =2Ddependent (on a specific CPU model). CPPC will normally report the hard= ware minimum and maximum values, and you have all values in-between at your= disposal to set the desired performance. However, besides the desired per= formance, there are two other controls: Requested minimum and maximum perfo= rmances (by contrast with the hardware limits, into which they must of cour= se lie). They limit the range in which the hardware is allowed to function= =2E The desired performance must lie between the minimum and maximum reque= sted. If all these values are not equal, the CPU is allowed (but not oblig= ed) to temporarily change its balance around the desired performance, which= is the other part of point 1). Setting all controls (minimum requested, d= esired performance and maximum requested) to the same value gives you some = exact performance level, which can further be tuned with the EPP value. >> For the future, we should probably eye at teaching powerd(8) about worki= ng with CPPC, (snip) > (snip) However, I think (2) would let powerd do a far better job and I'd = be very interested in getting CPPC to optionally expose more frequencies an= d not do any automatic governing. All CPPC controls I have mentioned are going to be exposed for AMD hardware= very soon (reviews have been validated, I'm still polishing and testing so= me and will commit tomorrow probably). Goal is to expose the same controls= for Intel hardware (which actually has some more, but that are tied to poi= nt 1)) in a second step. Then, what will be needed is to enhance powerd(8) to actually use these con= trols instead of setting frequencies (once CPPC is enabled, it's not possib= le to set frequencies, at least directly). Some experimentations will be n= eeded to find the right policies, as the spec leaves an important leeway to= hardware implementors. Policies may have to be tuned to the CPU brand, an= d even further to specific CPU models. E.g., on some AMD CPU I'm testing, = the EPP value has absolutely no effect (whether in autonomous mode or not),= and the size of the range of the requested minimum and maximum does not se= em to matter (that still needs more experiments), so basically only the des= ired performance has an effect. On other Intel CPUs I tested, the EPP valu= e has an important effect (in autonomous mode). =2D-=20 Olivier Certner --nextPart4304977.aWEtfRnraa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmmLkzcACgkQjKEwQJce Jid/TQ//a8Be0fH6NoH80o1XHmQf5SAn+jqeltTZSRYjiYFgFLLGUm0OsN9rFEx9 kuvxagmKsayAbwZJBuOxk2+m8xVDA7r4L910Y0adNHmSmAIckrsfnPCbETavsS/X BAt1QA5UwicKMhiRvRVut78NW3nUJcIXZybR97fHhZ1wZnteQRsdii+ZGcxs9f8c duivBTT/NLoP7EkrTWbESRcATdvxXCi3CuUhqG/px8Ro1m4Xzt2bDn2KixddPeWA JtkvbUHj1Zi/CuL69PY1Qi/3MEJnvdJTrcJC/cMyvW2vU+mczr0XkkLO17UdK7/U MGQhlAFkrZCU14UKRPjjkeQsn44s3lMwP/hzA4mIiNd566caorU/4aKMXnofaCrY sRU6YU/DyipGZ+8UbkEYVibQs35uSz488rzAcLEJWJNaoyrAaVOl+wq43wdI+4r7 MD4geluh7DcXKhui7uczhoTDoPUtSt3SIbiD2Ca/HnuRmBJayXVDkGzv5gG1ixI9 7DLWdW+8MCwNkPziiNw+0O1gUMKrAUQxlS8K0maXz+7EcLhdi/GgsLyEoNTUzqC6 UtUReB+myNedrTyeY6vmj/kg7JALlFtQBwmRbv4+qM5k8AaAk8dzZS5mNKQtMi2z 6xocja/JtbiASo6vC8flsEMnVeZ8/ufy/r2SvwhOzcpvKmuAjV8= =GPSP -----END PGP SIGNATURE----- --nextPart4304977.aWEtfRnraa-- From nobody Wed Feb 11 20:25:26 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fB90q0HJ9z6S8mQ for ; Wed, 11 Feb 2026 20:25:31 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yx1-xb135.google.com (mail-yx1-xb135.google.com [IPv6:2607:f8b0:4864:20::b135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fB90p2Zy0z3GVY for ; Wed, 11 Feb 2026 20:25:30 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=KMOTw4D4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ianfreislich@gmail.com designates 2607:f8b0:4864:20::b135 as permitted sender) smtp.mailfrom=ianfreislich@gmail.com Received: by mail-yx1-xb135.google.com with SMTP id 956f58d0204a3-649b5f5570fso1984664d50.0 for ; Wed, 11 Feb 2026 12:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770841528; x=1771446328; darn=freebsd.org; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=FTxMj4VIegyiNefDnyMODFuzwqyFu6nr6OYasE84bAs=; b=KMOTw4D436HCsEzuekOPpKh74zMpTUBBHzO+OPZVQDxEMT6K8ivQI7t41hHZrl062V s/6KlCZ7BdelRxRHkUz/9/9dwFMs50KVOwPi77QAEr0MLyblNrWJj6DMRBwqHsUdBguL xcjCcPKTcA+KzEMcRjjQAvKZSl2CvYkd4fcG8MwLJ9FJCmR9fpW/s2zXeVUG+HPvAb4w jjBIif4FGM2oukMcBQuPt4sbNDPYTAlsiuZ8pBUJlZnIAqeY3UsD2LwZ2h6FVgQOv7Ry vQItd4wVHRBuGM1IjDsKO5bwesRLUcjRXfnrJqWJ7T1RvtGW3OM1bH98MnKFtF0Pac4Q E1Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770841528; x=1771446328; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=FTxMj4VIegyiNefDnyMODFuzwqyFu6nr6OYasE84bAs=; b=HEmDTswteIcJGsOvQCH91HlT/G/eWeb7f2cBr7LA475yBn8qwCj5xdsMgkevc7F+ag pJ7DyKaMyS8Ur1CTB+8+1bwIs4VKpCdNq771Io+5TtyRPje9wOiFOb3AIX+GdZanBeK7 RI+ozWGB33itxbdmOBCE6z9Wp14Rz4mlo91eTM5viCmipOvpnnbj8J5cHrwMrNpMeJLP Z28EE8m8ojqTSxzZmebnqb+rTNmpYr4reKEDt60whqKOmqcm9uLeBQpdwSi+QLK4FECL Yn6Tk1bq2iEFZWNa2zoZvQP57l19UFMXQGBptWid6bs+kdtuvzyK+2EeBQ8DaoduCXo+ 9uJg== X-Gm-Message-State: AOJu0Yy5CWKiXaG6c0OWCSrRbpoVPW8QR7eOjCUyacQvLW1tzxhNa0mC Iqb2ay6Ve5k+eiplIopHXxASrcq+/zgVg6x5w4Nlww0VtqTiIXKTFwNLOVWlkw== X-Gm-Gg: AZuq6aKJG+tqUFbqkaDySS9mlodfm3uvkScHXJQhlUpTiTZVTxbY4304GitN23U71/G /RfrZkFIGx7bzpvlxGFfKkogb2lYkCbvZ/u+aoXh3GhC8uZC8Ee4lC4S2YfUfCdoBxVEY+59mhS 6IkiRzeszfjOxpxwr21265vHAaWbkKApg20bn5Hz/4h6Wp1JZe/xfLhC1zAppKZPckl/GDDQxjv B6PPcJ0Z0JvnXeGiPokoCIdXwNHk54LTA+aHom8FMJQWOvJ02yJ78e9+MKnbTE4UmgHPhhbPe/j 4Z7k/TgW/oE24rgGlHVywg7wL5rG4z2CYOz1qT+Iv5DZACQh1tkE8hwXNPgNLZyxMknWt1amg7P ToE6bUh/3zm2f4+2bpS90EH72IDMs7HUPYZ9NLeZjijwXRcvh516bwe+DJ+ymjW6F59hlMKmxix XtaIc6+C4f3OfNQWF0XhJXaVQQGjnJ4EmctQrTO6nSyMEplg510gL5s1KbE/eNiYX1WMohBkruJ Kh4gQ== X-Received: by 2002:a05:690e:1553:20b0:64a:cf9d:8edc with SMTP id 956f58d0204a3-64bdf2c9145mr192105d50.4.1770841527695; Wed, 11 Feb 2026 12:25:27 -0800 (PST) Received: from ?IPV6:2600:1700:18f0:6812:129a:8666:ef01:3293? ([2600:1700:18f0:6812:129a:8666:ef01:3293]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-64afc73fe6asm2962415d50.0.2026.02.11.12.25.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Feb 2026 12:25:27 -0800 (PST) Message-ID: <742828d8-926a-4564-8f22-8cda1169f7cd@gmail.com> Date: Wed, 11 Feb 2026 15:25:26 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Thunderbird Daily Content-Language: en-US To: FreeBSD Current From: Ian FREISLICH Subject: Buildkernel failure (error: declaration of 'struct socket' will not be visible outside of this function) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b135:from] X-Rspamd-Queue-Id: 4fB90p2Zy0z3GVY X-Spamd-Bar: --- Hi In file included from /usr/src/sys/netpfil/pf/pfsync_nv.c:38: /usr/src/sys/netinet6/ip6_var.h:380:28: error: declaration of 'struct socket' will not be visible outside of this function [-Werror,-Wvisibility] 380 | int icmp6_ctloutput(struct socket *, struct sockopt *sopt); | ^ /usr/src/sys/netinet6/ip6_var.h:409:26: error: declaration of 'struct socket' will not be visible outside of this function [-Werror,-Wvisibility] 409 | int ip6_ctloutput(struct socket *, struct sockopt *); | ^ /usr/src/sys/netinet6/ip6_var.h:410:30: error: declaration of 'struct socket' will not be visible outside of this function [-Werror,-Wvisibility] 410 | int ip6_raw_ctloutput(struct socket *, struct sockopt *); | ^ /usr/src/sys/netinet6/ip6_var.h:429:27: error: declaration of 'struct socket' will not be visible outside of this function [-Werror,-Wvisibility] 429 | int rip6_ctloutput(struct socket *, struct sockopt *); | ^ /usr/src/sys/netinet6/ip6_var.h:430:24: error: declaration of 'struct socket' will not be visible outside of this function [-Werror,-Wvisibility] 430 | int rip6_usrreq(struct socket *, | ^ 5 errors generated. From nobody Thu Feb 12 14:28:08 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fBd2275j3z6RjG1 for ; Thu, 12 Feb 2026 14:28:10 +0000 (UTC) (envelope-from markj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fBd226LRsz3sP6; Thu, 12 Feb 2026 14:28:10 +0000 (UTC) (envelope-from markj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770906490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EjWZ9cQly3nxAAQM+/wiEa/zu1Yi19TtndGdWbYg2dE=; b=RQbQelRg6SnmZwcGv0qr32JdFWMdNaNcReELVmn4ujNfijVdd19DlB/ldq3C7qOHLQiJor /SmK//N34gfaFCPZUk2AFTOwrhGN7bFAsDWxyH4K1Lnxs7bS6PiRGCXQU/2psQ1m2/zsCF Xs58O4gtyMISJnNkwZiclsgowdJlwq6jWstg43KsNYl23L8eTEk3YtNXOGTyTvFOSD2PIn nrBvzLDMaBSJ2zs+yE3hv13f0RoCTRMEWH3Ttd9N1vmXes2+aB1ex8tLD3qiSHDbJr5Dwg SXdKLAXa72qtHrZjpac8VohMpaapB/YBme8nPbtAFlKkQaxDe+CEJVOD5KdFPg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770906490; a=rsa-sha256; cv=none; b=HZcuz9Or1ki69prAZ1zbS7ISRWCCBFiD/lSiWuFQ+x9Chkafjqm/B1CZOu3OuHQyiymmop 6kze0DAoKbcqcCwJnjUUkn8OVfsLAB81XnptPVF00p0WjqEuqiqUwUkHMKJB6scRpD1jyz f3vEgaaWMSSu3WbECUtogH4kw7bBlENe10TQXn/vy6aiBgC/TmYcC8i3RDfK57qppRBifa +UAn4DMVVmrY2Me5FCs8XEaUzlmJRz1mzLcnhsvrpYRs7DBObHG2WS4nVGHXijJF7WDREm zgUKpsYwhrVRhKag592qEaOV8Bvrwv1vI+06G+9cKH7I9tqODWw//cOzTcFo3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770906490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EjWZ9cQly3nxAAQM+/wiEa/zu1Yi19TtndGdWbYg2dE=; b=CbvZrsgsCf+Gkvi4JQuSEcaHA6YiysKxOIovS4oU9a7waM0YJm33AbrIYmDMYqCmH6CQjd c8Jh0FLPn6Em8nUI0/vfVQPZLaemka6XTTd4WQ3st++P7FGscPMEmFMgMHqsbO5lhNr4Au GJ89NO1YAjcEMdYgLNrswOKuV7K0zbaKmiWbVYPbR27Zu+91fkiUZClGovpoGEyNYQlFSy 8pqONXgsPC/vg83csWpVTiY5PyWt/Rh76nno5AcmaZHzWAZA2DiFtCdZ0S5dRAMORRCYuH aNtWiQbl7AHy6pYRVKYz8/jaZn8d1KhmafuPNiaz1qnGhvbK09mDY1kpWVxN/g== Received: from nuc (192-0-220-237.cpe.teksavvy.com [192.0.220.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: markj) by smtp.freebsd.org (Postfix) with ESMTPSA id 4fBd224BHJzqFR; Thu, 12 Feb 2026 14:28:10 +0000 (UTC) (envelope-from markj@freebsd.org) Date: Thu, 12 Feb 2026 09:28:08 -0500 From: Mark Johnston To: Ian FREISLICH Cc: FreeBSD Current Subject: Re: Buildkernel failure (error: declaration of 'struct socket' will not be visible outside of this function) Message-ID: References: <742828d8-926a-4564-8f22-8cda1169f7cd@gmail.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <742828d8-926a-4564-8f22-8cda1169f7cd@gmail.com> On Wed, Feb 11, 2026 at 03:25:26PM -0500, Ian FREISLICH wrote: > Hi > > In file included from /usr/src/sys/netpfil/pf/pfsync_nv.c:38: > /usr/src/sys/netinet6/ip6_var.h:380:28: error: declaration of 'struct > socket' will not be visible outside of this function [-Werror,-Wvisibility] > 380 | int icmp6_ctloutput(struct socket *, struct sockopt *sopt); > | ^ > /usr/src/sys/netinet6/ip6_var.h:409:26: error: declaration of 'struct > socket' will not be visible outside of this function [-Werror,-Wvisibility] > 409 | int ip6_ctloutput(struct socket *, struct sockopt *); > | ^ > /usr/src/sys/netinet6/ip6_var.h:410:30: error: declaration of 'struct > socket' will not be visible outside of this function [-Werror,-Wvisibility] > 410 | int ip6_raw_ctloutput(struct socket *, struct sockopt *); > | ^ > /usr/src/sys/netinet6/ip6_var.h:429:27: error: declaration of 'struct > socket' will not be visible outside of this function [-Werror,-Wvisibility] > 429 | int rip6_ctloutput(struct socket *, struct sockopt *); > | ^ > /usr/src/sys/netinet6/ip6_var.h:430:24: error: declaration of 'struct > socket' will not be visible outside of this function [-Werror,-Wvisibility] > 430 | int rip6_usrreq(struct socket *, > | ^ > 5 errors generated. I think you're using a custom kernel config, please share it when reporting build failures. In any case, I think commit be393b6f0497f374c679c31e746705515eb9a554 will fix the problem. From nobody Thu Feb 12 15:22:36 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fBfDz490Cz6RnwH for ; Thu, 12 Feb 2026 15:22:43 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fBfDz0qh4z42Nh for ; Thu, 12 Feb 2026 15:22:43 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-796d0395828so15731537b3.2 for ; Thu, 12 Feb 2026 07:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770909757; x=1771514557; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=iOKzR5Qp4zkiuREV+5DAS/W/xb1UEEqvr2/u+CbPcJ4=; b=i0ef60rno1aTQw2NJJrKu9gIb+hqur4qpJYEtj9AVnOEpSDz9Uqqu46Pzqsbl82hSa xNm2y1iNg9TqDcDTinWKLh+fPk9Nz+2QbHJKzqfqE5cTqC5CLwcgQku3FIjjx9P5o5cT 8711YmGmSOns+Crr5Xz+tSteqSBmzNdfLGMRfZz2ZnZ9HY4OJAh7lcYBIUQUjrZvpbLk QQKUr/x1g5pxD3kleMjzOGV4h6saQHEVlkV3SawXLHRr/1QwX7PW9oP8C0NQ4GioHCvi EBZbPMp2d0HxeVcM1kahfHp++/wkENwtp2xshoqZq8PcFlgbTKANNqOAxCE2SrCflt0X qskg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770909757; x=1771514557; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iOKzR5Qp4zkiuREV+5DAS/W/xb1UEEqvr2/u+CbPcJ4=; b=J+nJSD998gI0h6sxYuKri2DkSSC0yu2qv5hKuoQ5DdWpCvoUGnCJ54JfQ/mAErdGMo STXjEOnwY87pHm3GJFcQdsiukSzMJAsQNP+7DKEtqhscOzNY6cpxrXWSUIgqoBkYWkXY wP0XLTi5g2av3LNy7zKJYHNvzouiyEIS0YRnsXcy5A7mxImpq7M/1+rWyfuhda6yJtQo tV8PqX6RiUPn+Pt0VDXwisqravJqZNo9Nm10E8mA1x40ln5YVxsEkJ5xq4RQmVPfuIIT tK0XPF/vxpeC/hUQimjru/E0x/Wv66zpUr/R4OFA6cr4hPYgpALtD7VtdXMoeizmT8pr +SZQ== X-Gm-Message-State: AOJu0YzDe7/2ozIP6OrYUHv27qU7uXAP4DEx7sq51Ck8fMgNfEV0NyxG 9jnYb/7lergld4Jo701aaQ5szAOgoizpNPdSpqQT2D1MO545tO5KJvt7W8Q83Q== X-Gm-Gg: AZuq6aKdgBuYJ+QhgCSztZXo4XhUZhFnLIAG/q/dN903GWk7P+Aykv/FFuk5CKJxQQq OTGuYsSDVgUwd9LsSyGGyq2SGub3PMyAJGWG1fnZavP6Nh01vR8cEpuh4+zFSIf+SsyDIy2GKTT h1gobFGCXhOA9xnS6H3pJKXHKkIv26j4jQqAT6reCp52f+w9zLqj98BevzPfL0oJsbMGq4Zdsh9 PvIOoVqVWJX94FW2UgRae6VJ04UN8/EfkYcsFaVXvRbCLP5BPHge8d+zbqms5hiaNmYJSlDtJDB /pehEa296YJeG/+gI9h1DP+kvq6FUFHzYfsSG4+kRhW2P2GInYAql7Di9EmScVylZm3UUBYWLTc uOzMLSvCc8s23+65ZBtSoRGE6JHO3eWeelhBXnAPO8u9/TmchqxLjwWCm9Tf3C9gF9k8dPFcPCu NA9KJppwr/33Oo8b8pT2kpyKow3Qjn557pzJIZ9WH/9xXr4hpRCW4Fze6T+y84flnGiTeLo9df5 huKKQ== X-Received: by 2002:a05:690c:e372:b0:796:2fde:5dd4 with SMTP id 00721157ae682-797931b4d29mr16469287b3.48.1770909757269; Thu, 12 Feb 2026 07:22:37 -0800 (PST) Received: from ?IPV6:2600:1700:18f0:6812:129a:8666:ef01:3293? ([2600:1700:18f0:6812:129a:8666:ef01:3293]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7966c23f1bdsm48124427b3.28.2026.02.12.07.22.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Feb 2026 07:22:36 -0800 (PST) Message-ID: <4bbe4798-867d-4a08-8fb2-4c0b0b4b9f13@gmail.com> Date: Thu, 12 Feb 2026 10:22:36 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: Buildkernel failure (error: declaration of 'struct socket' will not be visible outside of this function) To: Mark Johnston Cc: FreeBSD Current References: <742828d8-926a-4564-8f22-8cda1169f7cd@gmail.com> Content-Language: en-US From: Ian FREISLICH In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4fBfDz0qh4z42Nh X-Spamd-Bar: ---- On 2/12/26 09:28, Mark Johnston wrote: > On Wed, Feb 11, 2026 at 03:25:26PM -0500, Ian FREISLICH wrote: >> Hi >> >> In file included from /usr/src/sys/netpfil/pf/pfsync_nv.c:38: >> /usr/src/sys/netinet6/ip6_var.h:380:28: error: declaration of 'struct >> socket' will not be visible outside of this function [-Werror,-Wvisibility] >> 380 | int icmp6_ctloutput(struct socket *, struct sockopt *sopt); >> | ^ >> /usr/src/sys/netinet6/ip6_var.h:409:26: error: declaration of 'struct >> socket' will not be visible outside of this function [-Werror,-Wvisibility] >> 409 | int ip6_ctloutput(struct socket *, struct sockopt *); >> | ^ >> /usr/src/sys/netinet6/ip6_var.h:410:30: error: declaration of 'struct >> socket' will not be visible outside of this function [-Werror,-Wvisibility] >> 410 | int ip6_raw_ctloutput(struct socket *, struct sockopt *); >> | ^ >> /usr/src/sys/netinet6/ip6_var.h:429:27: error: declaration of 'struct >> socket' will not be visible outside of this function [-Werror,-Wvisibility] >> 429 | int rip6_ctloutput(struct socket *, struct sockopt *); >> | ^ >> /usr/src/sys/netinet6/ip6_var.h:430:24: error: declaration of 'struct >> socket' will not be visible outside of this function [-Werror,-Wvisibility] >> 430 | int rip6_usrreq(struct socket *, >> | ^ >> 5 errors generated. > > I think you're using a custom kernel config, please share it when > reporting build failures. In any case, I think commit > be393b6f0497f374c679c31e746705515eb9a554 will fix the problem. That fixes the problem. Out of interest what option would have included the struct socket definition? Ian From nobody Thu Feb 12 15:49:42 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fBfr86334z6RrMS for ; Thu, 12 Feb 2026 15:49:44 +0000 (UTC) (envelope-from markj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fBfr85Qkwz45b2; Thu, 12 Feb 2026 15:49:44 +0000 (UTC) (envelope-from markj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770911384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KNOcue3Es60osufDcNqJJuD8WDNnDSoEKOlftXRmQMo=; b=OXmbLLmHd6aqgPjzVIffWlR/wiAR882M/5iRUmyyF1+36j5ZMNmFT1SG9qHcAz+Zk/YvIc aGm8NqSKbstVkE6mVa5wT+kM8zkfT787G08+uJj2acYl21ewAFDabLsCPVbU+SeN6kXSY6 8d6cALlE1yyLLA3Scej2KmjqgVapOjheFW1yGiTp45AZTa1DFoab9SsUOqqM5JduWGQ3fx 0HJscd+vwHjXEEPsPsiUvMcnTPSj/e4lwwb5t2F1wjECreyK67tdslo1ZZinae/+ejg7WD U4Vi9euQfYlV1oB6hgxfOETvKLMno4iBghqXH2pDTkJ8Vw/f/LDXR0zMbc3tvw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770911384; a=rsa-sha256; cv=none; b=QIGATL8o4Z9bhnEliCgoAkOK7MaZBfSQiCbZXJqtxok3NlaGwrkI73fSytQzLWO8jd5BvU I+BoCS7dbazYgJCX6uzNEGo+9TzU8BNuwTqATZCWlYh+0oDG0SiZml1uiL3pphZBzPxrZc T29yVXeksanXRI0HioDWkLY1dDhM2wlJt17fwLvxZ85W0s6q1xgdJRYNtoCqwGP3b8HU0w +YNX7buHK4p1v2vaFoPmNDX0N9EQLREiKxVINKTV3o09BZR/dWkXLk6K3gYWDl1rlLVjnr eeHvNhcjT0ShDwJBvSc+J3GT+u8uHdohP/2aLj9WK/u9SXLe1zEzLAP+LQLxiA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770911384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KNOcue3Es60osufDcNqJJuD8WDNnDSoEKOlftXRmQMo=; b=XMk09cM/fHdaIEwn+Ivsx5oMj6zzObtlrDbWq6PUAskYUeOiAviMgWzCT6JqfK8twV+INc 7LQmZ3Im/7nlZd3cW8hioH7X3G1v+3UPcK2BWhe/Mt+iKQBXmn2+mNFZ0H+jGbaZlP3yPo 32W8MySJgO2ppxn/GtYUqDsto4syRE6syZ2HJ4B8odbASr79oTmOFl1/dbBLmdHdSHCItW rAktihcVDLxixFdwf5t5NID96o9signEElpOYqre2bpIDE8jACFlQVKymDLeP3YxMyBtOT aErGXydSlrNxVeDzafcvFjYZ4XD3GTgtoqZC0M1AqFp/Ot5a9BP7elln89PHBw== Received: from nuc (192-0-220-237.cpe.teksavvy.com [192.0.220.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: markj) by smtp.freebsd.org (Postfix) with ESMTPSA id 4fBfr83TvlzrY3; Thu, 12 Feb 2026 15:49:44 +0000 (UTC) (envelope-from markj@freebsd.org) Date: Thu, 12 Feb 2026 10:49:42 -0500 From: Mark Johnston To: Ian FREISLICH Cc: FreeBSD Current Subject: Re: Buildkernel failure (error: declaration of 'struct socket' will not be visible outside of this function) Message-ID: References: <742828d8-926a-4564-8f22-8cda1169f7cd@gmail.com> <4bbe4798-867d-4a08-8fb2-4c0b0b4b9f13@gmail.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bbe4798-867d-4a08-8fb2-4c0b0b4b9f13@gmail.com> On Thu, Feb 12, 2026 at 10:22:36AM -0500, Ian FREISLICH wrote: > On 2/12/26 09:28, Mark Johnston wrote: > > On Wed, Feb 11, 2026 at 03:25:26PM -0500, Ian FREISLICH wrote: > > > Hi > > > > > > In file included from /usr/src/sys/netpfil/pf/pfsync_nv.c:38: > > > /usr/src/sys/netinet6/ip6_var.h:380:28: error: declaration of 'struct > > > socket' will not be visible outside of this function [-Werror,-Wvisibility] > > > 380 | int icmp6_ctloutput(struct socket *, struct sockopt *sopt); > > > | ^ > > > /usr/src/sys/netinet6/ip6_var.h:409:26: error: declaration of 'struct > > > socket' will not be visible outside of this function [-Werror,-Wvisibility] > > > 409 | int ip6_ctloutput(struct socket *, struct sockopt *); > > > | ^ > > > /usr/src/sys/netinet6/ip6_var.h:410:30: error: declaration of 'struct > > > socket' will not be visible outside of this function [-Werror,-Wvisibility] > > > 410 | int ip6_raw_ctloutput(struct socket *, struct sockopt *); > > > | ^ > > > /usr/src/sys/netinet6/ip6_var.h:429:27: error: declaration of 'struct > > > socket' will not be visible outside of this function [-Werror,-Wvisibility] > > > 429 | int rip6_ctloutput(struct socket *, struct sockopt *); > > > | ^ > > > /usr/src/sys/netinet6/ip6_var.h:430:24: error: declaration of 'struct > > > socket' will not be visible outside of this function [-Werror,-Wvisibility] > > > 430 | int rip6_usrreq(struct socket *, > > > | ^ > > > 5 errors generated. > > > > I think you're using a custom kernel config, please share it when > > reporting build failures. In any case, I think commit > > be393b6f0497f374c679c31e746705515eb9a554 will fix the problem. > > That fixes the problem. Out of interest what option would have included the > struct socket definition? I suspect it's "options VIMAGE".