Date: Tue, 16 Jul 2024 20:27:00 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Colin Percival <cperciva@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, Peter <pmc@citylink.dinoex.sub.org>, freebsd-stable@freebsd.org, Baptiste Daroussin <bapt@freebsd.org> 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: <ZpPCADUpmCFHNa49@disp.intra.daemon.contact> <3598c6db-6d8a-4efa-b5fc-1fc697608860@freebsd.org> <20240716063356.f0993ae6f7648ae19c1ae33f@dec.sakura.ne.jp> <0fb67778-d279-420b-b482-5ce36e08a1be@freebsd.org> <CANCZdfqVyj6mkLdkTKqKwK=8_7ugJ6esLj=ZkaHXOsU6UwVMeA@mail.gmail.com> <22612d5f-3960-4390-a484-3bd307820126@freebsd.org> <CANCZdfqZ%2BM38BH7TvAi%2BgTARAaf7-uChh0Hra85q8soQ%2B5nRew@mail.gmail.com> <25a443cb-35d3-4d32-bb94-7aa18d4a3813@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Jul 2024 16:58:16 -0700 Colin Percival <cperciva@freebsd.org> wrote: > On 7/15/24 15:59, Warner Losh wrote: > > On Mon, Jul 15, 2024 at 4:20 PM Colin Percival <cperciva@freebsd.org > > <mailto:cperciva@freebsd.org>> 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 <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240716202700.548354a58e17831bee7ab449>