From nobody Thu Aug 29 20:55:10 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 4WvtpN1dvgz52cSP for ; Thu, 29 Aug 2024 20:55:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) (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 4WvtpM6skjz4NmL for ; Thu, 29 Aug 2024 20:55:23 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-846b934981aso76672241.3 for ; Thu, 29 Aug 2024 13:55:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724964922; x=1725569722; h=content-transfer-encoding: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=EWDY6z36HJeBErzeCXBdbOXfFuWKzBqfI1paEQmXAvQ=; b=ffzQ1JXcoWOxJx5k+kdqZNMKl6kN0zxpcpnWrCO/PlmgQXuVZlOKJF3oF1xYo/vM4I 0RnDvH04k6TLawdiS6/N9x8autWnEAcSOjgbAJliozBltWUqod15PpUdmYHdakGfWgS0 iZyahtoiyyDqrkWfYDLnvA4prTclteViWg5RDM/FCk5fOO+1WT89lgJ7BJRzKLY07NPs XoygzCjzDyIW58LS371FQwrwa5dEMosTpRKz49SFD+mTkttoRCC8cb8byCS+B2pdSpRJ VvRzIe2ZzbkVWFYCtfuY7cOvACfAlZmuVDBULdRYRe+4tdqSlERgbqdb5IA+BHcXvDb8 edDg== X-Gm-Message-State: AOJu0YxJSJeRy2rC4UAMg0K869Qlbsbi734Mfxrx7Ay2qzU+LVhkAw0b o7y3m+j270DtwwdUefnZkUpp7JaroxSEYlDIRnGYxeeW8sB9zGNTvJe/cexQySfP9F8tluJ/evt Oz4e+AwkOSIP4dtMl4d32ppYDvPXXwQ== X-Google-Smtp-Source: AGHT+IG8g+/oOVfJip356EGYWMzsGmuiraxFnieZl9GbxWlHocNc9sZmerRtkXfL4Wa+JR8gB1b5WKHsVqnhKK+qD1E= X-Received: by 2002:a05:6102:d8d:b0:48f:de85:2b4c with SMTP id ada2fe7eead31-49a5af35cebmr4718332137.23.1724964922355; Thu, 29 Aug 2024 13:55:22 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Thu, 29 Aug 2024 14:55:10 -0600 Message-ID: Subject: Re: A Demo of rust-in-base To: Shawn Webb Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WvtpM6skjz4NmL On Thu, Aug 29, 2024 at 2:21=E2=80=AFPM Shawn Webb wrote: > > Hey Alan et al, > > I apologize for the silence on my end. It has been a busier two months > than anticipated. In that time, I've been entertaining some thoughts > on Rust in base support. ${LIFE} is starting to calm down again, and I > do believe I'll be able to start the research in time in September. I > will be splitting my free time between this and studying for my OSCP > cert. > > So, to those thoughts, in list form (in no particular order): > > 1. Use of Rust compiler toolchain support will be for userland > components in an opt-in fashion. Meaning, all userland components > written in Rust will be optional. > 2. It does not make sense to perform a vendor import of the Rust > compiler toolchain and standard libraries. All Rust code in the src > tree must be built from an external toolchain. > 3. I believe the notion of an external toolchain could be abstracted > such that we can support any optional userland component written in > a language supported by that external toolchain. This would imply > that other alternative languages could be supported with minimal > work (Zig, TypeScript, Python, Java, etc.) > 4. We could provide auto-detection mechanisms for determining which > external toolchains are available, their language support, etc. The > initial proof-of-concept would likely be limited to Rust to save on > time and complexity. > 5. As the work matures, and perhaps as a requisite for eventual > inclusion, we could land support for more than Rust. This might be > a step too far, but hey, it's one of the thoughts I had. > 6. So all of this wrapped up means that: > A. This is NOT a call to rewrite everything in Rust. This work will > only permit NEW, OPTIONAL components to be written. > B. Other languages/toolchains/ecosystems could be supported, not > just Rust. > C. Initial focus is on userland components. Rust in the kernel is > out of scope for this initial proof-of-concept. > D. I would like to see Rust in the kernel. That would be a good > next area of focus once userland support reaches some level of > maturity. > > My first goal will be to get a better understanding of > src.git/Makefile and src.git/Makefile.inc1. As I study that, I'll also > study your work, Alan. I really appreciate the time you have taken. I > might reach out to you and Warner directly for further questions. Relying on an external toolchain and allowing for future external toolchains other than Rust sounds like a really good plan. Conceivably we could even ditch our Lua import and use the same mechanism for that (but please, save Lua discussion for a separate flame war ;) ). I anticipate that the next big decisions will be "what components are so important that they musn't require an external toolchain?" and "how much cargo crate bloat is too much?". But we can cross those bridges when we come to them. I look forward to seeing your work, and please don't hesitate to ask for help. -Alan