Date: Tue, 3 Sep 2024 12:25:19 -0600 From: Warner Losh <imp@bsdimp.com> To: Alan Somers <asomers@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-ID: <CANCZdfqPJsOsK6Sf%2BTD3Tw_JEYuxi4hY4g1q%2BTDXMFr%2Bbw96%2BQ@mail.gmail.com> In-Reply-To: <CAOtMX2go95=RFjegzchgMTYNdZfatzGDVcavp8O6=bK9yks1bQ@mail.gmail.com> References: <202409031532.483FW0If007252@critter.freebsd.dk> <CANCZdfrhK1iTZL5uxciqK_FGb%2Bzha_NZ15LsY42f%2B_z3KbPmJw@mail.gmail.com> <CAOtMX2go95=RFjegzchgMTYNdZfatzGDVcavp8O6=bK9yks1bQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000b8aed506213b2e97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 3, 2024 at 12:18=E2=80=AFPM Alan Somers <asomers@freebsd.org> w= rote: > On Tue, Sep 3, 2024 at 12:10=E2=80=AFPM Warner Losh <imp@bsdimp.com> wrot= e: > > > > > > > > On Tue, Sep 3, 2024 at 9:32=E2=80=AFAM Poul-Henning Kamp <phk@phk.freeb= sd.dk> > wrote: > >> > >> As part of the migration, we yank LLVM out of the src. > > > > > >> > >> "pkg upgrade" also upgrade kernel and userland packages - Welcome to > >> the century of the fruitbat. > > > > > >> > >> And yes, we have ports written in Rust, why do you ask? > > > > > > pkgbase is the path forward. It is the future. We are better off puttin= g > all our > > horses behind that effort so we can make it the default install in 15.0= . > > > > Once we have that, this whole debate becomes moot, for the most part. > > Userland in rust can compete with userland in C. And with go, python, e= tc > > for whatever does the job the best. If rust is so much better, then > people > > will use it, otherwise they will use the C version. > > How will pkgbase handle the private interface problem? For example, > libifconfig and the /dev/cam/ctl ioctls are both unstable. A port > that uses one of those and is built for FreeBSD 14.0 won't necessarily > work for 14.1. As long as those interfaces' consumers are all within > src there's no problem, but if they move to ports then they'll need to > be rebuilt everytime the libifconfig or kernel port, respectively, > gets rebuilt. > Ah yes. That ABI would have to become stable on stable branches, just like all other ABIs we support. Otherwise, you have to build for all possibilities, which is tricky, or you have to have targeted binaries, which is tedious and error prone, especially for people who are running -stable instead of a release point. Absent a stable ABI, all bets are off. I'm surprised it's not more stable: the rest of CAM is certainly ABI stable across multiple major FreeBSD releases. pkg is close to providing the per-minor-release thing to try to solve the drm-kmod / virtualbox .ko issues. This is one of the features that would need to be fixed, imho, for pkgbase. Though mostly that's because of the port .ko problem. Warner --000000000000b8aed506213b2e97 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 Tue, Sep 3, 2024 at 12:18=E2=80=AF= PM Alan Somers <<a href=3D"mailto:asomers@freebsd.org">asomers@freebsd.o= rg</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= ">On Tue, Sep 3, 2024 at 12:10=E2=80=AFPM Warner Losh <<a href=3D"mailto= :imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com</a>> wrote:<br> ><br> ><br> ><br> > On Tue, Sep 3, 2024 at 9:32=E2=80=AFAM Poul-Henning Kamp <<a href= =3D"mailto:phk@phk.freebsd.dk" target=3D"_blank">phk@phk.freebsd.dk</a>>= wrote:<br> >><br> >> As part of the migration, we yank LLVM out of the src.<br> ><br> ><br> >><br> >> "pkg upgrade" also upgrade kernel and userland packages = - Welcome to<br> >> the century of the fruitbat.<br> ><br> ><br> >><br> >> And yes, we have ports written in Rust, why do you ask?<br> ><br> ><br> > pkgbase is the path forward. It is the future. We are better off putti= ng all our<br> > horses behind that effort so we can make it the default install in 15.= 0.<br> ><br> > Once we have that, this whole debate becomes moot, for the most part.<= br> > Userland in rust can compete with userland in C. And with go, python, = etc<br> > for whatever does the job the best. If rust is so much better, then pe= ople<br> > will use it, otherwise they will use the C version.<br> <br> How will pkgbase handle the private interface problem?=C2=A0 For example,<b= r> libifconfig and the /dev/cam/ctl ioctls are both unstable.=C2=A0 A port<br> that uses one of those and is built for FreeBSD 14.0 won't necessarily<= br> work for 14.1.=C2=A0 As long as those interfaces' consumers are all wit= hin<br> src there's no problem, but if they move to ports then they'll need= to<br> be rebuilt everytime the libifconfig or kernel port, respectively,<br> gets rebuilt.<br></blockquote><div><br></div><div>Ah yes. That ABI would ha= ve to become stable on stable branches,</div><div>just like all other ABIs = we support. Otherwise, you have to build for all</div><div>possibilities, w= hich is tricky, or you have to have targeted binaries,=C2=A0 which</div><di= v>is tedious and error prone, especially for people who are running -stable= </div><div>instead of a release point. Absent a stable ABI, all bets are of= f. I'm surprised</div><div>it's not more stable: the rest of CAM is= certainly ABI stable across multiple</div><div>major FreeBSD releases.</di= v><div><br></div><div>pkg is close to providing the per-minor-release thing= to try to solve the</div><div>drm-kmod / virtualbox .ko issues.</div><div>= <br></div><div>This is one of the features that would need to be fixed, imh= o, for pkgbase.</div><div>Though mostly that's because of the port .ko = problem.</div><div><br></div><div>Warner</div><div><br></div></div></div> --000000000000b8aed506213b2e97--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqPJsOsK6Sf%2BTD3Tw_JEYuxi4hY4g1q%2BTDXMFr%2Bbw96%2BQ>