From nobody Mon Aug 25 12:09:29 2025 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 4c9V390BJpz65hch for ; Mon, 25 Aug 2025 12:09:41 +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 4c9V3836Rjz4Mqk for ; Mon, 25 Aug 2025 12:09:40 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.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 57PC9TLa074162; Mon, 25 Aug 2025 21:09:30 +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=1756123770; bh=C+hvbCgzRKrs7GtpjYmtZ7J/SyLo2IoImzVrwZMUwTg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=C9QYgFE9SHRo7By4s6ToPWV4bCefGAicV58zE18s5CesdsqAkQrSFIrexnb1WLZ5f 6+8EgEsz89AsnDjRKUGNhshsloO0VbzBV5KEcGrcyWRPR1bO9ZhY/MdWHH0kcEyn0e hZL9vOt9b01Qg5MwpUponyeVzAYqodtKmJ2XglTw= Date: Mon, 25 Aug 2025 21:09:29 +0900 From: Tomoaki AOKI To: cyric@mm.st Cc: freebsd-current@freebsd.org Subject: Re: UPDATING stuff Message-Id: <20250825210929.b12e4cca5f799935c1ae3e00@dec.sakura.ne.jp> In-Reply-To: <1684d15d-c0eb-4206-832c-f59c582a6d67@mm.st> References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <548137ff7d2289fa60a1cba14afa4957@Leidinger.net> <1684d15d-c0eb-4206-832c-f59c582a6d67@mm.st> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) 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: 8bit X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4c9V3836Rjz4Mqk On Mon, 25 Aug 2025 18:39:08 +0700 cyric@mm.st wrote: > Warner Losh wrote: > > > > > > On Mon, Aug 25, 2025 at 3:13 AM Alexander Leidinger > > > wrote: > > > > Am 2025-08-25 10:44, schrieb Marcin Cieslak: > > > On Thu, 21 Aug 2025, Alexander Leidinger wrote: > > > > > >>>> COMPAT_FREEBSD14?  (Recently [gs]etgroups were changed, with > > >>>> compatibility syscalls moved to COMPAT_FREEBSD14). > > >> > > >> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a > > >> try tomorrow. But would this also affect the zfs dataset stuff? > > > > > > This thread could have been a simple UPDATING update.  I think > > this is > > > the fourth > > > time or so I have run into problems, because the changes were not > > > explained. > > > > > > UPDATING entry on VMM got only there after I've spent 2 days+ > > > troubleshooting > > > my wifibox failures. > > > > > > When I read your message I was immediately thinking you might need > > > "COMPAT_FREEBSD14", > > > but, again, I couldn't find any obvious entry neither in the docs nor > > > in > > > the git log I was looking at. > > > > > > @glebus - maybe during the stabilization effort the changes done > > to the > > > tree > > > could be reviewed and documented? > > > > > >  - where the FreeBSD_version got bumped and why > > > > This is normally documented in > > https://docs.freebsd.org/en/books/porters-handbook/versions/ > > > > (intended > > to be updated at the time when the FreeBSD_versions is increased), > > but I > > can agree that the info there is a bit terse sometimes. > > > > >  - ABI changes > > >  - .... > > > > > > For example it could be useful to be able to find the information > > "what > > > does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file. > > > Otherwise I can't be sure if I need that option or "is my system > > fresh > > > enough" > > > to remove it from the kernel. > > > > > > It provides the system call interface as of FreeBSD 14. As new system > > calls are added that replace old ones, they are moved to being > > conditional on COMPAT_FREEBSD14. You should never remove the > > COMPAT_FREEBSDX when you are on current X+1. It's a recipe for pain. > > FreeBSD 14 binaries still might not always work (there are companion > > issues with shared library bumps for our non-symbol-versioned libraries > > too: there you have to wait for new compat14 package and/or play libmap > > games since the major bump usually is compatible enough to run most old > > programs but not always and not perfectly... libmap is at best a stop-gap). > >   > > > > What do you think about this? > > diff --git UPDATING UPDATING > > index ddb2e7603b2a..e197940c6431 100644 > > --- UPDATING > > +++ UPDATING > > @@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW: > >          If you only have FreeBSD-sendmail installed for applications > > that > >          require libmilter, you can now remove it. > > > > +20250815: > > +       The [gs}etgroups(2)syscalls have changed. To maintain backwards > > +       compatibility with existing programs, you need COMPAT_FREEBSD14 > > in > > +       your kernel config until all applications which use this are > > +       rebuild/reinstalled. > > + > >   20250815: > >          jemalloc 5.3.0 has been committed to the tree. > > > > > > I'd make it stronger. We should proactively create a COMPAT_FREEBSD15 > > just after the branch and add it to GENERIC. You 100% of the time want > > this if you aren't updating every last binary on your system each and > > every time you update. We should add that to our checklist to do eary, > > rather than late, as needed. It shouldn't be buried in an obscure entry, > > but advice we always give for everybody, all the time. GENERIC has it in > > there, which is why most people won't see this issue. > I wonder why it's not done the other way around, having the options to > *exclude* the compat bits so there are no surprises for users with > custom kernel configs. Creating kernel config from scratch is discouraged now. Why not including such as GENERIC, GENERIC-NODEBUG, MINIMAL and MINIMAL-NODEBUG (there are more candidates exist) and add or remove options / devices by options / nooptions and device / nodevice? For example, GENERIC-NODEBUG on main simply includes GENERIC, disables unneeded options via including std.nodebug and name itself as GENERIC-NODEBUG. https://cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC-NODEBUG https://cgit.freebsd.org/src/tree/sys/conf/std.nodebug Now you can create, for example, a config file that includes GENERIC, name it by ident line and "nooptions COMPAT_FREEBSD14" line to drop FreeBSD 14 compatibility support. ===== Example ===== include GENERIC ident NO14SUPPORT nooptions COMPAT_FREEBSD14 ===== End example ===== Not 100% sure, but IIRC, ancient kernel configs which needed separate config process on building kernel didn't have include functionality, thus, needed to create full config. But it's not needed now. -- Tomoaki AOKI