On Wed, Aug 26, 2026 at 01:03:44PM -0500, Kyle Evans wrote: K> > On Wed, Aug 26, 2026 at 01:15:27PM -0400, John Baldwin wrote: K> > J> > J> Note that C++ doesn't allow this at the language level. When I converted ctld to K> > J> > J> C++ I had to adjust some enums to be simple #define's instead in the ctl headers. K> > J> > K> > J> > Noted. I can't make a judgement if it is a smart restriction by C++ or not. K> > J> > In our case using enums as flags is common and handy and Werror=assign-enum in K> > J> > combination with __attribute__((flag_enum)) will make this use fortified K> > J> > against mistakes. K> > J> K> > J> Mostly my point is that over time we may be forced to convert away from enums to K> > J> plain constants if more of the base system starts using C++ anyway. At least for K> > J> enums exposed to userspace. K> > K> > But if C++ doesn't allow flag enums in principle, then they just can't go into K> > userspace headers, no matter how we compile the kernel. Basically we already K> > are there, and enabling Werror=assign-enum for kernel won't change anything, K> > will it? K> > K> I don't really have comments on the rest of this, but at least one of our downstreams does K> use C++ in the kernel and it'd be nice if we didn't have anything too critical require too K> heavy of patching to work in that environment.
This basically means we can't use flag enums in KPIs, but we can internally. My recent sweep through the code seems to confirm that we don't have any KPIs that use flag enums. Note. Actually it is possible to use C flag enums in C++ with cast: Flags f = static_cast<Flags>(FLAG_A | FLAG_B); Not saying that we should propose such KPIs. On other hand, if we ever get to massive use of C++ in kernel, we can propose a specific C++ KPI with class enums and specific C KPI with flag enums. -- Gleb Smirnoff
