From nobody Tue Jul 16 11:27:00 2024 X-Original-To: freebsd-stable@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 4WNcHX0wDhz5R7bP for ; Tue, 16 Jul 2024 11:27:36 +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 4WNcHW2Nr2z42dB; Tue, 16 Jul 2024 11:27:34 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 46GBR0Q8074366; Tue, 16 Jul 2024 20:27:01 +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=1721129222; bh=kX8970US2lFY7Za2SL5RACLxPTeLdvZIa/6H2f2ThvY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=R64GYOn+S1Sf/f8F6mJGt1qsC7w0Z4G+Y1mTsO1pG6mr4xkqKoil9GlTmIW/B/K66 Q2ZAhC439jkAB1xyRqM0TN++k3tkLRFl/y6UnmRoCAXb27pFGY+VU3/CpcXURSe6xQ 6vJLH9SYuCeO8HVZiKzO9wzX0sqrS4voUW3dfz2U= Date: Tue, 16 Jul 2024 20:27:00 +0900 From: Tomoaki AOKI To: Colin Percival Cc: Warner Losh , Peter , freebsd-stable@freebsd.org, Baptiste Daroussin Subject: Re: Change to FreeBSD release scheduling etc. Message-Id: <20240716202700.548354a58e17831bee7ab449@dec.sakura.ne.jp> In-Reply-To: <25a443cb-35d3-4d32-bb94-7aa18d4a3813@freebsd.org> References: <3598c6db-6d8a-4efa-b5fc-1fc697608860@freebsd.org> <20240716063356.f0993ae6f7648ae19c1ae33f@dec.sakura.ne.jp> <0fb67778-d279-420b-b482-5ce36e08a1be@freebsd.org> <22612d5f-3960-4390-a484-3bd307820126@freebsd.org> <25a443cb-35d3-4d32-bb94-7aa18d4a3813@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- 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: 4WNcHW2Nr2z42dB On Mon, 15 Jul 2024 16:58:16 -0700 Colin Percival wrote: > On 7/15/24 15:59, Warner Losh wrote: > > On Mon, Jul 15, 2024 at 4:20 PM Colin Percival > > wrote: > > > > On 7/15/24 15:05, Warner Losh wrote: > > > Ideally, we'd keep the same KBI per major release, but that ideal has > > fallen > > > short. > > > > Having a stable KBI only solves half of the problem.  With DRM especially it's > > useful for people running the latest minor release to use kmods which make use > > of functionality which was added in the latest release before the previous > > release is EoLed. > > > > Functionality added where? I'm not following the point you're making here... > > But since > > KBI stability isn't going to happen (at least given our past track record and > > a lack of > > tools to enforce it), it may be just an academic exercise. > > New functions in LinuxKPI is the case I was thinking of. It doesn't prevent > kernel modules compiled for earlier releases working with the newer release, > but because we build kernel modules on a per-stable-branch basis we have to > wait until the previous release EoLs. It would be the one most frequently happening recently. For environments where updating/upgrading via freebsd-update are not provided (like main and stable branches), admins are basically requited to update/upgrade base via src. These cases, they can put kmod ports into PORTS_MODULES variable in /etc/src.conf, thus basically no problem. Unfortunately, this WAS not enough true for drm-*-kmod ports as they often took behind and "broken time window" persisted until they catch up with base. But fortunately, at least for stable/14, it seems to be significantly stabilized thanks to the tireless efforts of graphics team. So, remaining problem would be the screams/sighs on forums.freebsd.org when any binary kernel updates (patch releases) are provided via freebsd-update, and/or when someone attempted to upgrade their base to non-*.0 releases on different stable branch (i.e., upgrade from 13.2 to 14.1) while previous point release is still not EOL'ed. As admins should be strongly encouraged to run latest patch (-p*) release of the point release they are using, kmod pkgs should be provided for latest patch release only on single point releases. (Means, when 14.0 is at 14.0-p3 and 14.1 is at 14.1-p1, and 14.0 is not yet EOL'ed, kmod pkgs for 14.0-p3 and 14.1-p1 should be provided.) > > -- > Colin Percival > FreeBSD Release Engineering Lead & EC2 platform maintainer > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid -- Tomoaki AOKI