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]

Date: Wed, 10 Jan 2024 11:25:29 -0500
From: Neal Gompa <neal@...pa.dev>
To: Jason Gunthorpe <jgg@...dia.com>
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 10:52 AM Jason Gunthorpe <jgg@...dia.com> wrote:
>
> 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)
>


For what it's worth, I'm totally in favor of C++20 as well. I've
mostly written C++17 as of late and it is really nice to me, but I'm
genuinely excited about C++20 and newer revisions.

I also think that Linux adopting C++ and intentionally adopting safety
features that exist and are being added to C++ over time would also
further encourage the ecosystem to use them as well as make the Linux
codebase much easier to work with.


-- 
真実はいつも一つ！/ Always, there's only one truth!