From nobody Sun Aug 4 03:37:36 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 4Wc4yd1Qgbz5S0KH for ; Sun, 04 Aug 2024 03:37:45 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wc4yZ0hRcz4s5H for ; Sun, 4 Aug 2024 03:37:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dec.sakura.ne.jp header.s=s2405 header.b=G9z9Txgx; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4743baP2080746; Sun, 4 Aug 2024 12:37:37 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1722742657; bh=AmblL0NKxyRpUSQXNY+DcfhGlkNWMMBSddXBEye9me8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=G9z9TxgxPEWCxOo/ge0ujhAzr72gSXxBTNe12ls+kg0YG461W6HQyKapCP3+h87AQ sfJ6Vk/J+dMEh3TGR18Dt4Jmc/0eBCIrz++/b/cwIj+PsqDeHeUg4odZKXk858mRwp 4nnK0t2qTgrmzh1pRdFsR8dR0M5MYA70ZQOHJrAU= Date: Sun, 4 Aug 2024 12:37:36 +0900 From: Tomoaki AOKI To: Theron Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-Id: <20240804123736.3db9da477c91659775d3c530@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.20 / 15.00]; URIBL_RED(3.50)[dec.sakura.ne.jp:dkim]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_ANON_DOMAIN(0.10)[]; ONCE_RECEIVED(0.10)[]; BAD_REP_POLICIES(0.10)[]; HAS_ORG_HEADER(0.00)[]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; RCPT_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,meta]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4Wc4yZ0hRcz4s5H On Sat, 3 Aug 2024 20:41:22 -0400 Theron wrote: > On 8/3/24 13:36, Warner Losh wrote: > > We already have clang and gcc external tool chains, so there's a proven > > mechanism for that. But there's not a good notion of the concept "I have > > a rust compiler" or "I depend on rust". And there's no concept of crates > > or similar that rust programs use, but that will be one thorny area that > > we'll have to design for. Do we just pull them in and junk any notion of > > a reproducible build for these components into the future (since any crate > > can go away), or do we have a way to build up our own set of crates > > in the tree that the optional components depend on. How do we do change > > management on that if we have multiple programs that depend on a crate > > that's updated? how do we keep things fresh while not having update > > cascades be too burdensome a task. How does this tie into pkgbase? > > > > These are the things to think about. We don't need to solve all of > > them, but the Rust ecosystem is quite a bit different than the C ecosystem > > in the details of a number of these points, so we have to address them > > if we want to use Rust in base with the same traits as all the other bits > > in base today (or we need to have a thoughtful discussion on paradigm > > shift and settle on that). To my thinking, pkgbase might be a good way > > to segregate crates that are build from the base tree and express > > dependencies > > on optional components that use it, and have the ultimate dependency > > be a pkg from ports. > > > > These questions and design points aren't hard and aren't designed to > > block anything, but a bare minimum of what we need to articulate is the > > vision for these components. Likely a design document that spells these > > out in some degree of detail (or that we punt in this phase) would be good > > as well. I can help with that as well. > > > > Warner > > Rust must be adapted to the established practice of keeping base > dependencies in-tree, not the other way around.  Whatever shift of > thinking is required within Rust for cooperating with this kind of > stability within a project will be good for the Rust ecosystem as well. > > Theron Putting other problems (like managements of crates, moving goals) aside. At least, Rust components for base should be built with --crate-type=cdylib option [1] to allow dynamically linking with other components. Otherwise, base llvm/clang would be forced to generate Rust-style object format even for libc, I fear. [1] https://doc.rust-lang.org/reference/linkage.html -- Tomoaki AOKI