From nobody Sun Sep 8 13:50:56 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 4X1rwG2WfHz5TwJ0 for ; Sun, 08 Sep 2024 13:51:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 4X1rwF6fJ5z43Xt for ; Sun, 8 Sep 2024 13:51:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-20551eeba95so31458675ad.2 for ; Sun, 08 Sep 2024 06:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725803468; x=1726408268; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jqyZUrnH+1fG/GWLyEuvuOdaB2HskGsYRlp0PbuwTrE=; b=TWkgvuMJZQ8AxtQl7HUU7E37lzVKZYz58Hk+pX21xu1NkUMupfr0UGoo02JQnxVFtw UfDfdmACpfkHl4sIAj88Zcy6J794wY52vor/bMorxnLr9OPlUB/GB6Ur9KSsfRvE9l5O uM+QgTKe4uiNyRLh1Tq65oyi79HYe8Apm+1lzgR3UPIBzblePnBSfeggfopQ09EsFUSz MD1JyAsLOmSwVTh21VePLalxlHTPVfbgcF2YmP0tBVLmtz9VfvHYHWmrHFMy9rS4QrXL XlpSe1K4ePIQUY4fKKg+/MtSCO8mPFHHgiEvCkQ7XwC5jD2bT7BDHvrkPpLOfUj/b7hW 9twA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725803468; x=1726408268; h=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=jqyZUrnH+1fG/GWLyEuvuOdaB2HskGsYRlp0PbuwTrE=; b=Ve0DzaoLscbmKy0N7dDKmDFRIz14mb9z7/H0kzdwVwVQ4C7odbAbl3vM2YbkKu3v1k TS732ZxJwcIsntcnGKiUTSX5tiO6+efYsyfHHVvjaRdDTOoFdPPSxWclgHazjzChwlgT zLjIyk8R+TzYJIoKk7QZsIZdx2OtPoV5nGstctaQSn+9TRkR+IrglBlUHogfZ1q7RpAK 3yRS4dRSy/lG+CxJHM2BfMBCx2XYlTaZ+3g67Y1nkebzNVjJAR17rXUZc7LS+rwKPXwh qdqDa/ZPK+DZLblMJCPZSBVuU7/YApvCsifgaCXL2BL7A0X6EimN0CGvZbB/f87BVu57 ruww== X-Forwarded-Encrypted: i=1; AJvYcCWSy7lcHhLrie6L2WrWxVEGmh/lXwXCaf2Bqqx12sFJf/v0UahQLC/SeGPHALZvNsRfcMHYuDe4g+cde8vxu5c=@freebsd.org X-Gm-Message-State: AOJu0YzpKhOn97v3p26Obw0tqESDVHlDF/V+KzQ+HNbFeZnZZHgfEVZy A+mI0ep6snE/JlZ0+1YRilOy8CLxK/26G5LMa1rQEaTIduh/E9uJFlodkMwv5MLSddIUTTle697 P25tDlaNOzReDnXlszSrcZ1Wthxa7fGwn6N8KYg== X-Google-Smtp-Source: AGHT+IGKuaEAFQJoUX2bU026MZrcr4QFzdL2OAe5AlSdXC3bGEk94KX2i6+g5Qz3ah4Em+7FdIUX2YtpsnQW64MpVR4= X-Received: by 2002:a17:902:f60d:b0:205:6a4c:9a20 with SMTP id d9443c01a7336-206f053ade0mr93554425ad.34.1725803468395; Sun, 08 Sep 2024 06:51:08 -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: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> In-Reply-To: From: Warner Losh Date: Sun, 8 Sep 2024 07:50:56 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Kristof Provost Cc: David Chisnall , Poul-Henning Kamp , Alan Somers , Dmitry Salychev , Jan Knepper , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000afb91b06219bee0d" 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:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X1rwF6fJ5z43Xt --000000000000afb91b06219bee0d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Kristof On Sun, Sep 8, 2024 at 1:44=E2=80=AFAM Kristof Provost wro= te: > On 6 Sep 2024, at 9:41, David Chisnall wrote: > > The strategy document that I coauthored at Microsoft recommended the > following: > > - C++ conforming to the Core Guidelines and with static analysis for > existing C/C++ projects with the C parts incrementally migrated to C++. > > While I=E2=80=99d be interested in seeing Rust demonstrated there are cle= arly > still some practical issues to work out before we can, even in user space= . > > So, at the risk of derailing the Rust conversation, I want to ask about > C++. > > We already ship user space C++ code, what=E2=80=99s stopping us from doin= g so for > kernel code? > If we can get some of the benefit of a more modern language with much les= s > effort would that be a worthwhile step? RAII would not *always* make > reasoning about locks easier, but it would in at least 95% of cases. > > What would we need to do to be able to use C++ in the kernel? > So there's four big issues with C++ in the kernel, all surmountable if we wanted. There's the low-level allocation issues. Right now we know what memory is used by what because we have malloc enhanced to track this (oversimplifying a lot I know). So we'd need some framework to make it easy to have 'custom allocators' that could track it as well. At a bare minimum, we need the runtime support for new and delete... Next, there's all the other run-time support that's provided by compiler-rt= . Next, there's the issues of exceptions. They are quite useful for RAII (since you know dtors will get run when an error happens), and there'd need to be some sane plan for these (or we'd have to forego them). Finally, there's getting the subset of the standard library that's useful into the kernel. There's a lot of templates for facilitating RAII that are needed, for example, and some subset of STL, etc. Once you have those 'table stakes' issues out of the way, you'll need to see how it performs, and work out a few dozen logistical issues surrounding what compiler flags to use, what language features to enable/disable, how to optimize and what set of warnings are sensible. You could start using C++ with just the second of these items. Warner --000000000000afb91b06219bee0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Kristof

On Sun, Sep 8, 2024 at 1:4= 4=E2=80=AFAM Kristof Provost <kp@freeb= sd.org> wrote:

On 6 Sep 2024, at 9:41, David Chisnall wrote:

The strategy document that I coauthored at Microsof= t recommended the following:

- C++ conforming to the Core Guidelines and with static an= alysis for existing C/C++ projects with the C parts incrementally migrated = to C++.

While I=E2=80=99d be interested in seeing Rust demonstrated= there are clearly still some practical issues to work out before we can, e= ven in user space.

So, at the risk of derailing the Rust conversation, I want = to ask about C++.

We already ship user space C++ code, what=E2=80=99s stoppin= g us from doing so for kernel code?
If we can get some of the benefit of a more modern language with much less = effort would that be a worthwhile step? RAII would not always make= reasoning about locks easier, but it would in at least 95% of cases.

What would we need to do to be able to use C++ in the kerne= l?


So there's fou= r big issues with C++ in the kernel, all surmountable if we wanted.

There's the low-level allocation issues. Right now we= know what memory is used by what because we have malloc enhanced to track = this (oversimplifying a lot I know). So we'd need some framework to mak= e it easy to have 'custom allocators' that could track it as well. = At a bare minimum, we need the runtime support for new and delete...
<= div>
Next, there's all the other run-time support that= 9;s provided by compiler-rt.

Next, there's the= issues of exceptions. They are quite useful for RAII (since you know dtors= will get run when an error happens), and there'd need to be some sane = plan for these (or we'd have to forego them).

= Finally, there's getting the subset of the standard library that's = useful into the kernel. There's a lot of templates for facilitating RAI= I that are needed, for example, and some subset of STL, etc.

=
Once you have those 'table stakes' issues out of the way= , you'll need to see how it performs, and work out a few dozen logistic= al issues surrounding what compiler flags to use, what language features to= enable/disable, how to optimize and what set of warnings are sensible.

You could start using C++ with just the second of the= se items.

Warner
--000000000000afb91b06219bee0d--