Date: Sun, 4 Aug 2024 13:27:25 -0600 From: Warner Losh <imp@bsdimp.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Alan Somers <asomers@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: A Demo of rust-in-base Message-ID: <CANCZdfp3N7HSXK2yW2N6BCFS3aNJwJNiozpnhUvJUOAVX_H9rA@mail.gmail.com> In-Reply-To: <202408041904.474J4b9e050871@critter.freebsd.dk> References: <CAOtMX2gdt8xYyLR3peYWhov-161-6d7%2B8L6TiHCCyw1NQyspXw@mail.gmail.com> <202408041800.474I0HUM050473@critter.freebsd.dk> <CAOtMX2ht0EinR4G56gN6z=gQuJDAHfnE0JPOo7E6hSWC1=dDzA@mail.gmail.com> <202408041820.474IKjVV050602@critter.freebsd.dk> <CAOtMX2gh8O1OntWhBzhZLv6sFt9WHwWgOu8LmLWU3YQGYks=Uw@mail.gmail.com> <202408041904.474J4b9e050871@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sun, Aug 4, 2024, 1:05 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > Alan Somers writes: > > On Sun, Aug 4, 2024 at 12:20=E2=80=AFPM Poul-Henning Kamp > <phk@phk.freebsd.= > > dk> wrote: > > > > How is that different from any other dependency management in ports ? > > > > Because those two components need to be updated in lock-step with > > potentially any git commit to the base system. Not just official > > releases, even minor ones. > > I'm not trying to be glib here: I really want to make sure I understand > any fine nuances you are trying to communicate. > > Isn't that precisely what drm-kmod already deals with ? > There's two issues with drm-kmod. 1 is KPI and keeping up. That's pretty easy to manage in the grand scheme of things. The other is KBI and matching the kernel. The massive inlining in linuxkpi make a stable KBI basically impossible (I did it for much of 12.x, and that was a nightmare because it broke faster than I had time to fix it). Warner -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > [-- Attachment #2 --] <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 4, 2024, 1:05 PM Poul-Henning Kamp <<a href="mailto:phk@phk.freebsd.dk">phk@phk.freebsd.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">--------<br> Alan Somers writes:<br> > On Sun, Aug 4, 2024 at 12:20=E2=80=AFPM Poul-Henning Kamp <phk@phk.freebsd.=<br> > dk> wrote:<br> <br> > > How is that different from any other dependency management in ports ?<br> ><br> > Because those two components need to be updated in lock-step with<br> > potentially any git commit to the base system. Not just official<br> > releases, even minor ones.<br> <br> I'm not trying to be glib here: I really want to make sure I understand<br> any fine nuances you are trying to communicate.<br> <br> Isn't that precisely what drm-kmod already deals with ?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There's two issues with drm-kmod. 1 is KPI and keeping up. That's pretty easy to manage in the grand scheme of things.</div><div dir="auto"><br></div><div dir="auto">The other is KBI and matching the kernel. The massive inlining in linuxkpi make a stable KBI basically impossible (I did it for much of 12.x, and that was a nightmare because it broke faster than I had time to fix it).</div><div dir="auto"><br></div><div dir="auto">Warner</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> -- <br> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20<br> phk@FreeBSD.ORG | TCP/IP since RFC 956<br> FreeBSD committer | BSD since 4.3-tahoe <br> Never attribute to malice what can adequately be explained by incompetence.<br> <br> </blockquote></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp3N7HSXK2yW2N6BCFS3aNJwJNiozpnhUvJUOAVX_H9rA>
