From nobody Sat Jan 20 23:22:47 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 4THXb923kkz57khC for ; Sat, 20 Jan 2024 23:23:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4THXb909Dvz3xJw; Sat, 20 Jan 2024 23:23:01 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-6e0e99adb3bso37213a34.3; Sat, 20 Jan 2024 15:23:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705792980; x=1706397780; 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=5+nheKYWjyJAhguRS4x6qy7OD35oLuxTy7hLcuxjrMA=; b=RxqAe595nKhzFJ1YLnyCBkkH0ZfDcjE/4r9TUJcRQ5a/lP3kr0NxX15QaogpxJOeoj KnCC6nr9xiCqBqfNdqIwDqfh/bkXVrb561eH1IEqCfIOPobZVCAFD3b1arOiYDkv9Kjl sn5AtIWuNN8QCSJi9axPJQRgUc3cDEv4dWp4aeBe3F8i5S9x6/R7QGB5UgE4Ottl6Ae9 8VnfKwt8wO+sIc7FmtqXc06xgHa03LmFuzGVyniiR0+R2KBeTSnsKHinZLm9Otgds/c0 oPG9yMGXUeskYQWf2rv0imgGuwiw4Z1HmiUOI6SyAk13Hoe635GbtEpM2jcjW1K5BwHa D+0w== X-Gm-Message-State: AOJu0YyC2xq6TkBbvi3RaXgQ9EKVlTv+1XpN09tLEbDpRiD5uL+3zzh2 sWVo9M8LdAZP/rz95cs5LAdx8cYvHLt1ETKYbE/slvwkA2mKXNbsMxfeRJfaa2vD+bOYJUSkAkZ pT8j6k2XH/eWDr+HRW3ewd4CBhdc= X-Google-Smtp-Source: AGHT+IHYtCa+Riz3HDe9D5wOJfj3B4Uxkdcan/Q+V0kQCQ4sKNSligiYnuvMcRo3vnV0pIacUCxa3tHSR9cStFBkU/0= X-Received: by 2002:a05:6358:3413:b0:175:c179:7515 with SMTP id h19-20020a056358341300b00175c1797515mr1673126rwd.46.1705792979687; Sat, 20 Jan 2024 15:22:59 -0800 (PST) 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: <1673801705774097@mail.yandex.ru> In-Reply-To: From: Alan Somers Date: Sat, 20 Jan 2024 16:22:47 -0700 Message-ID: Subject: Re: The Case for Rust (in the base system) To: Warner Losh Cc: Aleksandr Fedorov , FreeBSD Hackers , Scott Long , "meka@tilda.center" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4THXb909Dvz3xJw 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] On Sat, Jan 20, 2024 at 3:31=E2=80=AFPM Warner Losh wrote: > > > > On Sat, Jan 20, 2024 at 11:45=E2=80=AFAM Aleksandr Fedorov wrote: >> >> What about external dependencies? >> >> https://github.com/Axcient/freebsd-nfs-exporter/blob/master/Cargo.toml#L= 19 >> https://github.com/asomers/gstat-rs/blob/master/gstat/src/main.rs#L20 >> >> Is there any plan for which crates we should take into the base system? >> >> We have had C++ in base for many years, but I don=E2=80=99t see any good= libraries for CLI, logging, JSON, etc. >> >> https://doc.rust-lang.org/rustc/platform-support.html#tier-1-with-host-t= ools >> >> Where is the support for Freebsd as a primary platform? ARM, RISC-V, Pow= er? Should we rewrite devd? >> >> I think we need to start by providing official repositories (e.g git.Fre= eBSD.org/rust.git or git.FreeBSD.org/go.git) >> for different languages that include stable bindings to the system API: >> - sysctl >> - libgeom >> - libifconfig >> - netgraph >> - jail >> - etc. >> >> So that it=E2=80=99s not just some anonymous on crates.io that represent= s these bindings, but our community. >> Officially, with support for a stable ABI for releases, security patches= , etc. >> >> After this, it will be possible to think about which components to inclu= de in the base system. >> >> I would be glad to see a more modern language than C in the database, bu= t I=E2=80=99m afraid that it will be like with C++, >> that we will get a couple of daemons and utilities and that=E2=80=99s al= l. > > > These are all good questions that need good answers, though necessarily t= o get started. > > But the other question that occured to me after my last posting was "What= about build integration?" > How much of the rust automation do we take in vs how much do we drive fro= m a future bsd.rust.mk. > I can sketch out bsd.rust.mk (to pick an arbitrary name, we'd likely need= one for what we traditionally > think of as libraries (which may or may not map 1:1 onto crates: we could= have c callable libraries > written in rust in the future, for example) and one for binaries. Initia= lly, though, if we go with the > 'make rust tests possible' then we'd likely need the appropriate packages= installed for whatever > dependencies we'd have in the tests. This would give us a taste for what = we'd need to do for > base, I'd think. Once we had that notion, I can easily see there needing = to be some sort of > rust bindings for ATF/kyua as one of the first libraries / crates that wo= uld test that aspect of > the build system. That all would be up to the people writing the tests in= rust, I'd imagine. > > While I could jot out the basics of this integration (so one could just a= dd the rust > tools to a subdir or subdirs, include the bsd.rust.mk or whatever and the= n it would build > if rust is enabled, and would emit a warning it was skipped because rust = was disabled). > We'd find out if this is workable or not and iterate from there. But that= would also require > active participation from the rust advocates to make it a reality: I can = put together the > build infrastructure for the disabled case, but likely can't on my own do= the rust enabled > case. I'd be happy to work with someone to do that, but I'm not going to = be able to do > that myself: my need for rust is slight, my knowledge of rust is weak, et= c. Working with > someone (or ideally several someones), though it could become reality. So= please contact > me if you'd like to work on this. That sounds like a reasonable approach. But what would be the first tool or test suite to write in Rust? The fusefs tests are now 16 kSLOC and I don't fancy rewriting them. The tests that I DO want to write are those that involve fsx-rs. But those won't actually need bsd.rust.mk, because they'll just be short sh scripts that invoke a tool from ports. I just need a ports committer to approve https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276005 . ATM I don't have a ready project to be imp's guinea pig. -Alan