From nobody Sun Jan 21 02:19:55 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 4THcWZ20QMz582Pj for ; Sun, 21 Jan 2024 02:20:10 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (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 4THcWZ05V7z4JX3; Sun, 21 Jan 2024 02:20:10 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-429fc7a1eacso21947191cf.2; Sat, 20 Jan 2024 18:20:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705803609; x=1706408409; 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=C1wkEMTjODFXuksI8+9RB/epgV0GbmEx+DFdhrV9n6k=; b=eilyj3BiUJxW7rSiF7WnUL66VZlARgIBhNQHAE12UmMLLNvnHKWFTsnaKmUWIVfLzD ScEitLCMN+LGbWerV01Y9YCHhhK2VE2fnvnIP97cWhs3giTGBSkWYVgCArZ+9wIgHHqL gp3kOkKThxs0+KyAqEqaPoOrrINcaz6fumKwM96nyLi1fgzhfJyjnRhCRwXGY65fc8WB 86pFxGS9U4dTgKhUyFl9hlShSwCNZecIPjEYVc0kjW3qCNOkLQF/Nv8P3kobPv2U33Gm oiqgC8cUozDQna1yD9QZZb9DhAErk6+sbBcyahKNoFmBAlnLdM2n0oR2ZzB7eJnsWgdz e7KQ== X-Gm-Message-State: AOJu0YyOneCcEBw1A96A2kDOPl69iuHwIiFq6OQMG8vu2dknb8+XmR7H 1j6hjJ0zCTVYwsUGkM7U4T7I7trlFBATQqf1N3t4P8M0ruQWlU0DO0JZxg6szBaMxFSWKHsMUk6 7C+SKGj9LJAEIU6KS+Ih3zoqIGME= X-Google-Smtp-Source: AGHT+IFxERWxsi7fN/b0dQr4kC4wL4U5Oqr+bpAl/V5KUNDuYowm0SWF3ulxqgIbtLbCTJ7mSsIYr+86SfNX+6tmJnk= X-Received: by 2002:a05:6214:21a6:b0:681:7571:c508 with SMTP id t6-20020a05621421a600b006817571c508mr3065955qvc.7.1705803607453; Sat, 20 Jan 2024 18:20:07 -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> <20240121110611.af567b0ac3a8fd8593ffcb7f@dec.sakura.ne.jp> In-Reply-To: <20240121110611.af567b0ac3a8fd8593ffcb7f@dec.sakura.ne.jp> From: Alan Somers Date: Sat, 20 Jan 2024 19:19:55 -0700 Message-ID: Subject: Re: The Case for Rust (in the base system) To: Tomoaki AOKI Cc: Warner Losh , 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: 4THcWZ05V7z4JX3 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 7:06=E2=80=AFPM Tomoaki AOKI wrote: > > On Sat, 20 Jan 2024 15:31:23 -0700 > 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.tom= l#L19 > > > 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 syste= m? > > > > > > We have had C++ in base for many years, but I don=E2=80=99t see any g= ood libraries > > > for CLI, logging, JSON, etc. > > > > > > > > > https://doc.rust-lang.org/rustc/platform-support.html#tier-1-with-hos= t-tools > > > > > > Where is the support for Freebsd as a primary platform? ARM, RISC-V, > > > Power? Should we rewrite devd? > > > > > > I think we need to start by providing official repositories (e.g > > > git.FreeBSD.org/rust.git or git.FreeBSD.org/go.git) > > > for different languages that include stable bindings to the system AP= I: > > > - sysctl > > > - libgeom > > > - libifconfig > > > - netgraph > > > - jail > > > - etc. > > > > > > So that it=E2=80=99s not just some anonymous on crates.io that repres= ents these > > > bindings, but our community. > > > Officially, with support for a stable ABI for releases, security patc= hes, > > > etc. > > > > > > After this, it will be possible to think about which components to in= clude > > > in the base system. > > > > > > I would be glad to see a more modern language than C in the database,= but > > > 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= all. > > > > > > > These are all good questions that need good answers, though necessarily= to > > get started. > > > > But the other question that occured to me after my last posting was "Wh= at > > about build integration?" > > How much of the rust automation do we take in vs how much do we drive f= rom > > a future bsd.rust.mk. > > I can sketch out bsd.rust.mk (to pick an arbitrary name, we'd likely ne= ed > > one for what we traditionally > > think of as libraries (which may or may not map 1:1 onto crates: we cou= ld > > have c callable libraries > > written in rust in the future, for example) and one for binaries. > > Initially, though, if we go with the > > 'make rust tests possible' then we'd likely need the appropriate packag= es > > installed for whatever > > dependencies we'd have in the tests. This would give us a taste for wha= t > > we'd need to do for > > base, I'd think. Once we had that notion, I can easily see there needin= g to > > be some sort of > > rust bindings for ATF/kyua as one of the first libraries / crates that > > would 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= add > > the rust > > tools to a subdir or subdirs, include the bsd.rust.mk or whatever and t= hen > > it would build > > if rust is enabled, and would emit a warning it was skipped because rus= t > > was disabled). > > We'd find out if this is workable or not and iterate from there. But th= at > > would also require > > active participation from the rust advocates to make it a reality: I ca= n > > 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 t= o be > > able to do > > that myself: my need for rust is slight, my knowledge of rust is weak, = etc. > > Working with > > someone (or ideally several someones), though it could become reality. = So > > please contact > > me if you'd like to work on this. > > > > Warner > > One way to go could be moving programs rewritten with rust to ports. > There are some programs (not in rust, though) moved to ports, like rcs. I've already done this with a few, though I didn't delete the C versions from base. usr.bin/gstat =3D> sysutils/gstat-rs tools/regression/fsx =3D> devel/fsx > > Currently, it would not be so realistic, but once we completely switch > to pkgbase, IIUC, programs in base can sanely depemd on ports programs, > excluding kernel and fundamental libraries. > > As non-rust consumers of graphics/librsvg2-rust can sanely link with > it, I assume kmods in ports written in rust can kldload'ed sanely. > This could be a good starting point. > > And would be not all, but test for rust libraries could be implemented > with C/C++ or any other language suitable, if the rust libraries can > sanely linked with test codes. Yes, if the Rust library implements a C interface, which most don't. > > Am I wrong?