From nobody Mon Jul 15 22:59:49 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 4WNHhx4crpz5QN7H for ; Mon, 15 Jul 2024 23:00:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 4WNHhx30ffz44NV for ; Mon, 15 Jul 2024 23:00:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-7163489149eso3538196a12.1 for ; Mon, 15 Jul 2024 16:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721084400; x=1721689200; 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=vBQ6Qew+AakdIuKgTjXTy2qol+w9TgFrWRFqV52AjOQ=; b=cxzmRUvnICJAvh7yjlEFBnr18PQyl+o8ziaAr/mvWvSVJFjFcDrTBkVpeA89QDhdzH dDNi8AwKoMUSs9UpPsuWQOn9qyX6qcNegzwNVOx6bGcYFx7q+yh1UtwJjywbGE0weEPS z773UdyPyBnIEMxQn42Z1jT/Ko6qzAJ+EMymjv+kThYd3XtGqVTcUWhW50QNc4iZGA3+ CGmNe+EUvJgYi921wILKzUN66WxlLLPDEHQgNZw/s0Z3IIQQnx8POm4J0iipJQDzH3fu ItTsvNxhIpUq/J+ZkLq3EqT3JHV38741vQtP3eLVS+lVe9wGSrcZe2tjb1f33d1opy8x qFSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721084400; x=1721689200; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vBQ6Qew+AakdIuKgTjXTy2qol+w9TgFrWRFqV52AjOQ=; b=hEVbcuKYnHlHY9rgBi4p0r73UYrWx1GrdCKD3hiGwkmiQokbi3udC9mFu60pw+EdeV 9oIBaUkyV9my+3Dn9g14XJN1a4pDM1FVQgq5fPhucneWEgeXoOmD/jixfvd7xORZ41E7 JdAozvAu7/RepiNrXOlaxsHY7kNQYOtKzIl0VGiKRVqBLKQ8Y9CNnrfcTpEN7K8wWW9J Jx43b70HQtHEiz7Jir8mibhTKVvzHqC0R6j7u019xXUkXJ3s2KMPL5MNk7uTuKURuMF8 JRt/rCPZwVTR6j6H3km37pu8Vl0K5iJKB8lnXrW7bDjgISL9LgDU4JRg8WG6Ygfj4mtg Cj3A== X-Forwarded-Encrypted: i=1; AJvYcCU66px1K8ItvGvWMjS11k5ePzvJDeJqOwHkMohlsNb2lwI3/6h8UkKPGmBbiL4j756YhogCZBpKMv6bX+yCC77ESXSN4lvOrKQ0cw== X-Gm-Message-State: AOJu0Yx/N8inasYCF7fH4L4JOHltcO0HbL0PD0kPeKJ1tHbDl7zC1i42 jGfjBN2igC878pNTNX0gHvfvrH/312BwQp1/F9aKLnP/L9ITuXHY4xKBZMh/kEO7mvrQOIEPHMr MkFdoJ3+zZO5teXoeC9Z3n57iapNyLERX7fvQMA== X-Google-Smtp-Source: AGHT+IGZgOqmA0LvO4e1lCncCfR5bZOFDJQiXDl6e0O8EmvBljCvPf6wYE2130SiKOt5AdZSknT3VcOckEv3+2IzCkM= X-Received: by 2002:a05:6a21:398b:b0:1c3:b61c:57cb with SMTP id adf61e73a8af0-1c3f12b5ae9mr400101637.53.1721084400173; Mon, 15 Jul 2024 16:00:00 -0700 (PDT) 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 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> In-Reply-To: <22612d5f-3960-4390-a484-3bd307820126@freebsd.org> From: Warner Losh Date: Mon, 15 Jul 2024 16:59:49 -0600 Message-ID: Subject: Re: Change to FreeBSD release scheduling etc. To: Colin Percival Cc: Tomoaki AOKI , Peter , freebsd-stable@freebsd.org, Baptiste Daroussin Content-Type: multipart/alternative; boundary="0000000000004d286e061d513030" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WNHhx30ffz44NV --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 wrote: > On 7/15/24 15:05, Warner Losh wrote: > > On Mon, Jul 15, 2024 at 3:57=E2=80=AFPM Colin Percival > > 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


=
On Mon, Jul 15, 2024 at 4:20=E2=80=AF= PM Colin Percival <cperciva@free= bsd.org> wrote:
On 7/15/24 15:05, Warner Losh wrote:
> On Mon, Jul 15, 2024 at 3:57=E2=80=AFPM Colin Percival <cperciva@freebsd.org > <mailto:c= perciva@freebsd.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0Flavouring kernel module ports for each minor relea= se -- possibly building in
>=C2=A0 =C2=A0 =C2=A0in an oldest-supported-release jail but with the re= levant /usr/src/sys tree --
>=C2=A0 =C2=A0 =C2=A0might work well?=C2=A0 But that's a question fo= r portmgr; I don't know enough about
>=C2=A0 =C2=A0 =C2=A0how package building works to know how feasible thi= s would be.
>
> People have talked about "stacking" repos to accomplish this= . We'd build per-minor
> release images for .ko's. I'm not sure what the sticking point= s are for doing
> this,
> though.

That would be good, but drm-14.1-61-kmod-6.1.69_2 (aka have multiple versio= ns
of ports and require users to kmod packages to pick the right now) would be=
better than what we have now.

Indeed, b= ut the upgrade path sucks for that. And all the infrastructure is in place<= /div>
to start doing the per-minor-release repos to augment the per maj= or release ones.
I'm unsure what the holdup is, though. I'= ;ve cc'd baptiste who may know.

It's the l= east bad solution, though. It solves the problem for release points, but
not for people on stable between releases (except accidentally some= times when
things haven't yet diverged), nor for current (sin= ce it's nothing but breakage of KBIs :).
For that problem, on= ly a build-from-source-for-each-new-kernel-build can work.
= =C2=A0
> 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.=C2=A0 With DRM especia= lly 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<= br> release is EoLed.

Functionality added w= here? I'm not following the point you're making here... But since
KBI stability isn't going to happen (at least given our past t= rack record and a lack of
tools to enforce it), it may be just an= academic exercise.

Warner
--0000000000004d286e061d513030--