From nobody Tue Sep 03 16:37:54 2024 X-Original-To: freebsd-hackers@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 4WyrsC0Kd6z5TXvF for ; Tue, 03 Sep 2024 16:38:07 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyrsB71yBz41vt; Tue, 3 Sep 2024 16:38:06 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725381486; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GRQuib22Wr22UiXEWbuoU1GpqzqYzwc/vSRInqnI7fo=; b=LAB0dl+KaIOYo7BhkPeBdPaNRlQKJBuV+zkX7xcozvp4cwYnTJpnXm/mFGNXosYjCmJjG6 bbcv5a8Bkf+1YoLe8X2hshtfwzVt/2vJV7zZDBXfDedupouoI9zhjJByv5Aklwp6zc3oMT 2S41As6oL4lhBovQFu7IJuDzCqWYyadAWIkLl2K4I6bcHwarlruOQztyeN5KWqWV68XKdc t5PrzpeZ9YF8oAwqU1m7HXfIvd1z+9fXN9vPf1Ivm21Uhba0WsjIe6etibEQTZrGPy9jnP e1h7PejLyg58fP4MjVd5Icg3K4AqHJhgrQmGD8NY+9QlHsRCWXt3/gw6POWFdg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725381486; a=rsa-sha256; cv=none; b=qzosZgeqNhGWH8ZYovaWwkrle/YoaGn9AA/p3OtLk5Cu2ITwlcRSytWRIvGR5Lrxn0bJeE uEKgkqMglQSO1RfpGsD0Rj1pmJF7iIn5FJICEmFeMeJ0Qt7FgREZdOkKe70x5UQSsLtK5M IsBhSR3Tza8BYCSklCnbsWeEWjgFukNaoV2bLQVWvmnwLVsyjsT/rZJkmZTJVacqsMsGhv /GtGtJa38Xp7jKaIZoI5EY46ybfQUpExZ3wNczYndTxpXmZQMwQX3tr74uBIvhdrKBe6kt zwh2TE12BKi6x8/NLdlyS35abx0Gda+27ZACBCwjPA5IEq0/7t/riDB1I9aq2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725381486; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GRQuib22Wr22UiXEWbuoU1GpqzqYzwc/vSRInqnI7fo=; b=lXssNs9W7wPc6am8ez+ADlbgiihIHQuUR02l+42A+xV/2uax33iTGIjIm9Mw+4kNpGnyMx CyhfakhXXKzNFa0nIoAgS+J95xLP+Eows6MGkna9QAt7Xk5YCyidaahs7bjBylIyvul9d8 8RviGR/YjQQyW/Xjnu2AVIsx97yRhyOLGylknfyrF0VO8LbCk3wJj87BFJXXvK0PMsv01s I3ipkMZ6VaZEYSMvRZrLc61KlWIaPomx1L7lnvAGT6wSZfxYhE14p4YKW30wle7l8MqFi2 hCo3ZQ/YHm1xnDJGnZ/jc4PVPksy788pWHVeMNfj3K4epafTewA+Yng/7QLppg== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WyrsB6R3Xz19kD; Tue, 3 Sep 2024 16:38:06 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 40F9C50D9; Tue, 03 Sep 2024 17:38:06 +0100 (BST) From: David Chisnall Message-Id: <8981BC7B-6487-4FE7-9965-23B911367D2B@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_FB95CE73-42F9-4563-85BF-C23FF84984B7" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Tue, 3 Sep 2024 17:37:54 +0100 In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> Cc: FreeBSD Hackers To: Poul-Henning Kamp References: <202409031532.483FW0If007252@critter.freebsd.dk> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_FB95CE73-42F9-4563-85BF-C23FF84984B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 3 Sep 2024, at 16:32, Poul-Henning Kamp wrote: >=20 > And when it does, LLVM, source code we import verbatim from an > entirely different project, and which no sane person would call > "Related to FreeBSD", takes up more than three quarters of the > compile time. It=E2=80=99s worse than that because, although we import the *source = code* verbatim (mostly, occasionally with a few back-ported or = not-yet-upstreamed fixes), we don=E2=80=99t import the *build system*. = We replicate a subset of what the upstream build system can do. > The only reason we do that, is because we stil have that outdated > "FreeBSD is src" emotional hangup. I don=E2=80=99t think this is quite the emotional hangup I have. It = doesn=E2=80=99t matter at all to me where the code lives. If we ripped = LLVM out of the src tree and built a package using the code that=E2=80=99s= currently in ports with CMake + Ninja + pkg, and made it part of the = core distribution, it would still be =E2=80=98FreeBSD=E2=80=99, because = it=E2=80=99s the POLA boundary. If I learn how something works in the bit of the system that is FreeBSD, = I don=E2=80=99t have to relearn it unless there=E2=80=99s a compelling = reason why the old abstractions can no longer reflect the new world = (around 9ish, there was a change in how WiFi was configured, for = example, but wired Ethernet for IPv4 is still configured the way I = learned in 4.x, because it got faster but not qualitatively different). Even though cc and c++ were gcc in 4.x and are clang now, I still invoke = them the same way. They now support newer things (C++23 and C2x, not = just C++98 and C99, hurray!), but the older things still mostly work the = same way. Similarly, anything that=E2=80=99s a library in the bit that is FreeBSD = is either marked as private, or has a stable ABI throughout (and, = ideally, beyond) a release series (LLVM does not have this property, = which is why we ship Clang, lld, lldb, and so on, as tools that use = LLVM, we don=E2=80=99t ship *LLVM* in the base system). If we ripped = contrib out of src and kept the same guarantee from the git clones of = the upstream things, that would be fine. I expect that FreeBSD 15.5=E2=80=99s C/C++ compiler will compile any = C/C++ compilation unit that FreeBSD 15.0=E2=80=99s does (with a = get-out-of-jail-free card for things that rely on undefined behaviour). = If it doesn=E2=80=99t, I expect that this is something that the project = will treat as a bug and work with upstream to fix it. =20 In contrast, if I install some compiler from the ports tree, I expect = different (not necessarily weaker) guarantees. I expect that the = version from packages-built-from-ports have the same guarantees as the = upstream project. This may be a 6-monthly release cycle with support = for things that fixed any deprecation warnings from the last two = releases. It may be a never-breaks-backwards-compatibility-ever = guarantee, depending on the program / library. For Rust in FreeBSD, I would expect one of two things: Option 1: FreeBSD rustc is not binary that we supported binary for = building anything outside of the base system. Rust code in the base = system may need updates to the compiler to be MFC=E2=80=99d at the same = time (again, I have no opinions about where the code *lives*, MFC may be = a submodule update, an update to a ports-like recipe, or a full code = import). We have a blessed set of packages. Option 2: FreeBSD rustc is supported for third-party things, minor = versions may bring in new ones, but within a release series we expect = full backwards compatibility with the exception of things that fix = soundness issues in the type checker (if cve-rs stops working within a = major release series, that=E2=80=99s a feature not a bug). I believe Rust now has strong enough guarantees for Option 2 to be = feasible (I=E2=80=99m not 100% sure). But that neither, to me, requires = bringing rustc into contrib. It requires providing a way of building an = atomic snapshot that is the things that we define as FreeBSD N, and = guarantees of compatibility between FreeBSD N.0 to N.M. Note that some of the stability guarantees are already quite complicated = and I think merit longer discussions. For example, I=E2=80=99m told = that some kernel modules broke across the 13.x series (in particular, = VirtualBox ones) and needed recompiling. My understanding was that we = went and added padding to data structures before a .0 series to prevent = this. If this isn=E2=80=99t the case, then we need to be more explicit = about *which* KBIs are stable / unstable across a major release. The = existence of LinuxKPI also complicates these discussions, because = LinuxKPI is a compat layer that tracks an unstable target (whatever = Linux is doing this week) and so, by definition, *cannot* have the same = stability guarantees as the base system, but it is necessary for = supporting most modern GPUs. If anything, some of these stability guarantees are *more* valuable now = than they have been for much of the last couple of decades. The Linux = world is struggling with containers because containers incorporate a = userland from some distro, but inherit the kernel from the host. Can = you run an Ubuntu 20.04 and 22.04 container on your host? Maybe. = FreeBSD is in a great position to ship a family of container base images = for major releases and get all of the benefits that container platforms = provide in terms of sharing from common images (two containers with the = same set of base layers can share disk and buffer cache space for the = common bits), while still providing the benefits of = latest-version-of-third-party-things via ports / packages. Being able = to have a single supported version of a FreeBSD 15 base layer with the = core libraries (and a set of additional layers that bring in = progressively more things) and expect people to just point at = freebsd15:latest as the base and rebuild their containers to pick up the = latest bits is great, but depends on the compatibility guarantees that = FreeBSD embodies (ABI for libraries, CLI for tools). =20 David --Apple-Mail=_FB95CE73-42F9-4563-85BF-C23FF84984B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 3 Sep = 2024, at 16:32, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote:

And when it does, LLVM, source code we = import verbatim from an
entirely different project, and which no sane person would = call
"Related to FreeBSD", takes up more than three quarters of = the
compile = time.

It=E2=80=99s = worse than that because, although we import the *source code* verbatim = (mostly, occasionally with a few back-ported or not-yet-upstreamed = fixes), we don=E2=80=99t import the *build system*.  We replicate a = subset of what the upstream build system can = do.

 The only reason we do = that, is because we stil have that = outdated
"FreeBSD is src" emotional = hangup.

I don=E2=80=99t think = this is quite the emotional hangup I have.  It doesn=E2=80=99t = matter at all to me where the code lives.  If we ripped LLVM out of = the src tree and built a package using the code that=E2=80=99s currently = in ports with CMake + Ninja + pkg, and made it part of the core = distribution, it would still be =E2=80=98FreeBSD=E2=80=99, because = it=E2=80=99s the POLA boundary.

If I learn how = something works in the bit of the system that is FreeBSD, I don=E2=80=99t = have to relearn it unless there=E2=80=99s a compelling reason why the = old abstractions can no longer reflect the new world (around 9ish, there = was a change in how WiFi was configured, for example, but wired Ethernet = for IPv4 is still configured the way I learned in 4.x, because it got = faster but not qualitatively different).

Even = though cc and c++ were gcc in 4.x and are clang now, I still invoke them = the same way.  They now support newer things (C++23 and C2x, not = just C++98 and C99, hurray!), but the older things still mostly work the = same way.

Similarly, anything that=E2=80=99s a = library in the bit that is FreeBSD is either marked as private, or has a = stable ABI throughout (and, ideally, beyond) a release series (LLVM does = not have this property, which is why we ship Clang, lld, lldb, and so = on, as tools that use LLVM, we don=E2=80=99t ship *LLVM* in the base = system).  If we ripped contrib out of src and kept the same = guarantee from the git clones of the upstream things, that would be = fine.

I expect that FreeBSD 15.5=E2=80=99s = C/C++ compiler will compile any C/C++ compilation unit that FreeBSD = 15.0=E2=80=99s does (with a get-out-of-jail-free card for things that = rely on undefined behaviour).  If it doesn=E2=80=99t, I expect that = this is something that the project will treat as a bug and work with = upstream to fix it.  

In contrast, if I = install some compiler from the ports tree, I expect different (not = necessarily weaker) guarantees.  I expect that the version from = packages-built-from-ports have the same guarantees as the upstream = project.  This may be a 6-monthly release cycle with support for = things that fixed any deprecation warnings from the last two releases. =  It may be a never-breaks-backwards-compatibility-ever guarantee, = depending on the program / library.

For Rust in = FreeBSD, I would expect one of two = things:

Option 1: FreeBSD rustc is not binary = that we supported binary for building anything outside of the base = system.  Rust code in the base system may need updates to the = compiler to be MFC=E2=80=99d at the same time (again, I have no opinions = about where the code *lives*, MFC may be a submodule update, an update = to a ports-like recipe, or a full code import).  We have a blessed = set of packages.

Option 2: FreeBSD rustc is = supported for third-party things, minor versions may bring in new ones, = but within a release series we expect full backwards compatibility with = the exception of things that fix soundness issues in the type checker = (if cve-rs stops working within a major release series, that=E2=80=99s a = feature not a bug).

I believe Rust now has = strong enough guarantees for Option 2 to be feasible (I=E2=80=99m not = 100% sure).  But that neither, to me, requires bringing rustc into = contrib.  It requires providing a way of building an atomic = snapshot that is the things that we define as FreeBSD N, and guarantees = of compatibility between FreeBSD N.0 to = N.M.

Note that some of the stability guarantees = are already quite complicated and I think merit longer discussions. =  For example, I=E2=80=99m told that some kernel modules broke = across the 13.x series (in particular, VirtualBox ones) and needed = recompiling.  My understanding was that we went and added padding = to data structures before a .0 series to prevent this.  If this = isn=E2=80=99t the case, then we need to be more explicit about *which* = KBIs are stable / unstable across a major release.  The existence = of LinuxKPI also complicates these discussions, because LinuxKPI is a = compat layer that tracks an unstable target (whatever Linux is doing = this week) and so, by definition, *cannot* have the same stability = guarantees as the base system, but it is necessary for supporting most = modern GPUs.

If anything, some of these = stability guarantees are *more* valuable now than they have been for = much of the last couple of decades.  The Linux world is struggling = with containers because containers incorporate a userland from some = distro, but inherit the kernel from the host.  Can you run an = Ubuntu 20.04 and 22.04 container on your host?  Maybe. =  FreeBSD is in a great position to ship a family of container base = images for major releases and get all of the benefits that container = platforms provide in terms of sharing from common images (two containers = with the same set of base layers can share disk and buffer cache space = for the common bits), while still providing the benefits of = latest-version-of-third-party-things via ports / packages.  Being = able to have a single supported version of a FreeBSD 15 base layer with = the core libraries (and a set of additional layers that bring in = progressively more things) and expect people to just point at = freebsd15:latest as the base and rebuild their containers to pick up the = latest bits is great, but depends on the compatibility guarantees that = FreeBSD embodies (ABI for libraries, CLI for tools). =  

David

= --Apple-Mail=_FB95CE73-42F9-4563-85BF-C23FF84984B7--