Date: Mon, 15 Jul 2024 16:59:49 -0600 From: Warner Losh <imp@bsdimp.com> To: Colin Percival <cperciva@freebsd.org> Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, 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: <CANCZdfqZ%2BM38BH7TvAi%2BgTARAaf7-uChh0Hra85q8soQ%2B5nRew@mail.gmail.com> In-Reply-To: <22612d5f-3960-4390-a484-3bd307820126@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000004d286e061d513030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2024 at 4:20=E2=80=AFPM Colin Percival <cperciva@freebsd.or= g> wrote: > On 7/15/24 15:05, Warner Losh wrote: > > On Mon, Jul 15, 2024 at 3:57=E2=80=AFPM Colin Percival <cperciva@freebs= d.org > > <mailto:cperciva@freebsd.org>> wrote: > > Flavouring kernel module ports for each minor release -- possibly > building in > > in an oldest-supported-release jail but with the relevant > /usr/src/sys tree -- > > might work well? But that's a question for portmgr; I don't know > enough about > > how package building works to know how feasible this would be. > > > > People have talked about "stacking" repos to accomplish this. We'd buil= d > per-minor > > release images for .ko's. I'm not sure what the sticking points are for > doing > > this, > > though. > > That would be good, but drm-14.1-61-kmod-6.1.69_2 (aka have multiple > versions > of ports and require users to kmod packages to pick the right now) would = be > better than what we have now. > Indeed, but the upgrade path sucks for that. And all the infrastructure is in place to start doing the per-minor-release repos to augment the per major release ones. I'm unsure what the holdup is, though. I've cc'd baptiste who may know. It's the least bad solution, though. It solves the problem for release points, but not for people on stable between releases (except accidentally sometimes when things haven't yet diverged), nor for current (since it's nothing but breakage of KBIs :). For that problem, only a build-from-source-for-each-new-kernel-build can work. > > 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 mak= e > use > of functionality which was added in the latest release before the previou= s > 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. Warner --0000000000004d286e061d513030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 15, 2024 at 4:20=E2=80=AF= PM Colin Percival <<a href=3D"mailto:cperciva@freebsd.org">cperciva@free= bsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex">On 7/15/24 15:05, Warner Losh wrote:<br> > On Mon, Jul 15, 2024 at 3:57=E2=80=AFPM Colin Percival <<a href=3D"= mailto:cperciva@freebsd.org" target=3D"_blank">cperciva@freebsd.org</a> <br= > > <mailto:<a href=3D"mailto:cperciva@freebsd.org" target=3D"_blank">c= perciva@freebsd.org</a>>> wrote:<br> >=C2=A0 =C2=A0 =C2=A0Flavouring kernel module ports for each minor relea= se -- possibly building in<br> >=C2=A0 =C2=A0 =C2=A0in an oldest-supported-release jail but with the re= levant /usr/src/sys tree --<br> >=C2=A0 =C2=A0 =C2=A0might work well?=C2=A0 But that's a question fo= r portmgr; I don't know enough about<br> >=C2=A0 =C2=A0 =C2=A0how package building works to know how feasible thi= s would be.<br> > <br> > People have talked about "stacking" repos to accomplish this= . We'd build per-minor<br> > release images for .ko's. I'm not sure what the sticking point= s are for doing <br> > this,<br> > though.<br> <br> That would be good, but drm-14.1-61-kmod-6.1.69_2 (aka have multiple versio= ns<br> of ports and require users to kmod packages to pick the right now) would be= <br> better than what we have now.<br></blockquote><div><br></div><div>Indeed, b= ut the upgrade path sucks for that. And all the infrastructure is in place<= /div><div>to start doing the per-minor-release repos to augment the per maj= or release ones.</div><div>I'm unsure what the holdup is, though. I'= ;ve cc'd baptiste who may know.</div><div><br></div><div>It's the l= east bad solution, though. It solves the problem for release points, but</d= iv><div>not for people on stable between releases (except accidentally some= times when</div><div>things haven't yet diverged), nor for current (sin= ce it's nothing but breakage of KBIs :).</div><div>For that problem, on= ly a build-from-source-for-each-new-kernel-build can work.<br></div><div>= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > Ideally, we'd keep the same KBI per major release, but that ideal = has fallen<br> > short.<br> <br> Having a stable KBI only solves half of the problem.=C2=A0 With DRM especia= lly it's<br> useful for people running the latest minor release to use kmods which make = use<br> of functionality which was added in the latest release before the previous<= br> release is EoLed.<br></blockquote><div><br></div><div>Functionality added w= here? I'm not following the point you're making here... But since</= div><div>KBI stability isn't going to happen (at least given our past t= rack record and a lack of</div><div>tools to enforce it), it may be just an= academic exercise.<br></div><div><br></div><div>Warner<br></div></div></di= v> --0000000000004d286e061d513030--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqZ%2BM38BH7TvAi%2BgTARAaf7-uChh0Hra85q8soQ%2B5nRew>