Date: Sun, 8 Sep 2024 07:50:56 -0600 From: Warner Losh <imp@bsdimp.com> To: Kristof Provost <kp@freebsd.org> Cc: David Chisnall <theraven@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Alan Somers <asomers@freebsd.org>, Dmitry Salychev <dsl@freebsd.org>, Jan Knepper <jan@digitaldaemon.com>, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <CANCZdfr03sUOz7AEZhTDmWPCPcA%2BqjRf4ZuUxs1FMi2xjnomWA@mail.gmail.com> In-Reply-To: <B355DB3E-82A2-407A-9D70-2A40C953DEB2@FreeBSD.org> References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> <B355DB3E-82A2-407A-9D70-2A40C953DEB2@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kp@freebsd.org> 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 <div dir=3D"ltr"><div dir=3D"ltr">Hey Kristof<br></div><br><div class=3D"gm= ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Sep 8, 2024 at 1:4= 4=E2=80=AFAM Kristof Provost <<a href=3D"mailto:kp@freebsd.org">kp@freeb= sd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex"><u></u> <div><div style=3D"font-family:sans-serif"><div style=3D"white-space:normal= "> <p dir=3D"auto">On 6 Sep 2024, at 9:41, David Chisnall wrote:</p> </div><div style=3D"white-space:normal"><blockquote style=3D"margin:0px 0px= 5px;padding-left:5px;border-left:2px solid rgb(19,107,206);color:rgb(19,10= 7,206)"><p dir=3D"auto">The strategy document that I coauthored at Microsof= t recommended the following:</p> <p dir=3D"auto"> - C++ conforming to the Core Guidelines and with static an= alysis for existing C/C++ projects with the C parts incrementally migrated = to C++.</p> </blockquote></div> <div style=3D"white-space:normal"> <p dir=3D"auto">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.</p> <p dir=3D"auto">So, at the risk of derailing the Rust conversation, I want = to ask about C++.</p> <p dir=3D"auto">We already ship user space C++ code, what=E2=80=99s stoppin= g us from doing so for kernel code?<br> 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 <em>always</em> make= reasoning about locks easier, but it would in at least 95% of cases.</p> <p dir=3D"auto">What would we need to do to be able to use C++ in the kerne= l?</p></div></div></div></blockquote><div><br></div><div>So there's fou= r big issues with C++ in the kernel, all surmountable if we wanted.</div><d= iv><br></div><div>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><= div><br></div><div>Next, there's all the other run-time support that= 9;s provided by compiler-rt.</div><div><br></div><div>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).</div><div><br></div><div>= 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.</div><div><br>= </div><div>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.</di= v><div><br></div><div>You could start using C++ with just the second of the= se items.</div><div><br></div><div>Warner</div></div></div> --000000000000afb91b06219bee0d--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr03sUOz7AEZhTDmWPCPcA%2BqjRf4ZuUxs1FMi2xjnomWA>