linux-kernel - Re: [PATCH 00/45] C++: Convert the kernel to C++

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240110155233.GA623732@nvidia.com>
Date: Wed, 10 Jan 2024 11:52:33 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Neal Gompa <neal@...pa.dev>
Cc: jirislaby@...nel.org, dhowells@...hat.com, hpa@...or.com,
	linux-kernel@...r.kernel.org, pinskia@...il.com,
	kent.overstreet@...ux.dev
Subject: Re: [PATCH 00/45] C++: Convert the kernel to C++

On Wed, Jan 10, 2024 at 08:04:53AM -0500, Neal Gompa wrote:
> Hey all,
> 
> I would like to speak in support of this too. It is not uncommon
> to see operating systems code written in C++ (notable examples are
> Haiku OS, Serenity OS, and Zircon/Fuschia) and I do feel that there
> are benefits to C++ for Linux code. Modern C++ (such as C++14 and
> newer), offers a lot of nice base language features that can make
> some of the kind of stuff that Linux does easier (as H. Peter Anvin
> has detailed in his post[1]).

Me too. If we are serious considering Rust I think C++20 deserves a
fair shake as well. Especially since I heard the C++ working group is
apparently looking at future C++ extensions for Rust-esque memory
safety these days.

I personally think the kernel community would have an easier and more
incremental time swallowing C++ than it would Rust, and C++17 is
already mature with fully working stable compilers. In particular I
feel someone familiar with C would have a easier ramp up to some
imagined "kernel C++20 subset" than to Rust.

Further, I feell that having a single base line of "all code compiles
in a C++20 compiler" and localized variations of what idiomatic style
and features different parts use would be ultimately more maintainable
than intermixing C and Rust togther.

I've also got a fair bit of experience with C++17 and I would add to
HPA's note that the modern idiomatic usage of C++17 is *way* different
than older versions. If someone was traumatized by early 2000's or
1990's C++ then it is not entirely fair to carry that to modern
C++17. Especially when combined with a modern environment with
something like clangd to help grok the code. (Though SFINAE is still
an inscrutable terror)

Jason