Received-SPF: pass (google.com: domain of linux-kernel+bounces-24459-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells <dhowells@redhat.com>
In-Reply-To: <86r0inmpbm.fsf@aarsen.me>
References: <86r0inmpbm.fsf@aarsen.me> <152261521484.30503.16131389653845029164.stgit@warthog.procyon.org.uk>
To: Arsen =?us-ascii?Q?=3D=3Futf-8=3FQ=3FArsenovi=3DC4=3D87=3F=3D?= <arsen@aarsen.me>
Cc: dhowells@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/45] C++: Convert the kernel to C++
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Jan 2024 09:20:03 +0000
Message-ID: <2154236.1705051203@warthog.procyon.org.uk>

Arsen Arsenovi=C4=87 <arsen@aarsen.me> wrote:

> >  (2) Constructors and destructors.  Nests of implicit code makes the co=
de less
> >      obvious, and the replacement of static initialisation with constru=
ctor
> >      calls would make the code size larger.
>=20
> This also disallows the primary benefit of C++ (RAII), though.  A lot of
> static initialization can be achieved using constexpr and consteval,
> too.

Okay, let me downgrade that to "I wouldn't allow it at first".  The primary
need for destructors, I think, is exception handling.  And don't get me wro=
ng,
I like the idea of exception handling - so many bugs come because we mische=
ck
or forget to check the error.

> It is incredibly useful to be able to express resource ownership in
> terms of automatic storage duration.

Oh, indeed, yes - but you also have to be careful:

 (1) You don't always want to wait till the end of the scope before releasi=
ng
     resources.

 (2) Expressing ownership of something like a lock so that it is automatica=
lly
     undone may require extra memory is currently unnecessary:

	struct foo {
		struct rwsem sem;
	};


	myfunc(struct foo *foo)
	{
		...
		struct foo_shared_lock mylock(foo->sem);
		...
	}

     This looks like a nice way to automatically take and hold a lock, but I
     don't think it can be done without storing the address of the semaphore
     in mylock - something that isn't strictly necessary since we can find =
sem
     from foo.

 (3) We could implement a magic pointer class that automatically does
     reference wangling (kref done right) - but we would have to be very
     careful using it because we want to do the minimum number of atomic ops
     on its refcount that we can manage, firstly because atomic ops are slow
     and secondly because the atomic counter must not overflow.

> >  (5) Function overloading (except in special inline cases).
>=20
> Generic code, another significant benefit of C++, requires function
> overloading, though.

I know.  But I was thinking that we might want to disable name mangling if =
we
can so as not to bloat the size of the kernel image.  That said, I do like =
the
idea of being able to have related functions of the same name with different
arguments rather than having to name each one differently.

> >  (7) 'class', 'private', 'namespace'.
>=20
> 'class' does nothing that struct doesn't do, private and namespace serve
> simply for encapsulation, so I don't see why banning these is useful.

Namespaces would lead to image bloat as they make the symbols bigger.
Remember, the symbol list uses up unswappable memory.

We use class and private a lot as symbols already, so to get my stuff to
compile I had to #define them.  Granted there's nothing intrinsically
different about classes and we could rename every instance of the symbol in
the kernel first.

When it comes to 'private', actually, I might withdraw my objection to it: =
it
would help delineate internal fields - but we would then have to change
out-of-line functions that use it to be members of the class - again
potentially increasing the size of the symbol table.

> >  (8) 'virtual'.  Don't want virtual base classes, though virtual functi=
on
> >      tables might make operations tables more efficient.
>=20
> Virtual base classes are seldom useful, but I see no reason to
> blanket-ban them (and I suspect you'll never notice that they're not
> banned).

You can end up increasing the size of your structure as you may need multip=
le
virtual method pointer tables - and we have to be very careful about that as
some structures (dentry, inode and page for example) we have a *lot* of
instances of in a running kernel.

> >  (2) Direct assignment of pointers to/from void* isn't allowed by C++, =
though
> >      g++ grudgingly permits it with -fpermissive.  I would imagine that=
 a
> >      compiler option could easily be added to hide the error entirely.
>=20
> This should never be useful.

It's not a matter of whether it should be useful - we do this an awful lot =
and
every case of assigning to/from a void pointer would require some sort of
cast.

David