The 5.7 kernel is out [LWN.net]

Linus has released the 5.7 kernel right on schedule. Headline features in 5.7 include x86 split-lock detection, thermal-pressure management, frequency invariance in the load-tracking code, coexistence between BPF and realtime preemption, support for BPF security hook programs (formerly called the KRSI security module), a new, Microsoft-blessed exFAT filesystem implementation, and more. The final patch to be merged was this one deprecating the long-standing 80-column limit for kernel source. See the KernelNewbies 5.7 page for lots of details.

to post comments

The 5.7 kernel is out

Posted Jun 1, 2020 14:00 UTC (Mon) by adobriyan (guest, #30858) [Link] (33 responses)

> long-standing 80-column limit

True story:

                        status = acpi_ds_method_data_get_node(ACPI_REFCLASS_ARG,
                                                              obj_desc->
                                                              reference.value,
                                                              walk_state,
                                                              ACPI_CAST_INDIRECT_PTR
                                                              (struct
                                                               acpi_namespace_node,
                                                               &obj_desc->
                                                               reference.
                                                               object));

I think I've seen "struct foo" split after "struct" as well.

The 5.7 kernel is out

Posted Jun 1, 2020 14:25 UTC (Mon) by pharm (guest, #22305) [Link] (7 responses)

At least clang-format does something sane with that:

status = acpi_ds_method_data_get_node(
    ACPI_REFCLASS_ARG, obj_desc-&rt;reference.value, walk_state,
    ACPI_CAST_INDIRECT_PTR(struct acpi_namespace_node,
                           &obj_desc-&rt;reference.object));

The 5.7 kernel is out

Posted Jun 1, 2020 14:27 UTC (Mon) by pharm (guest, #22305) [Link]

(weird errors in the above are my fault, not clang-format’s!)

The 5.7 kernel is out

Posted Jun 1, 2020 14:51 UTC (Mon) by adobriyan (guest, #30858) [Link] (5 responses)

clang-format does terrible things to carefully aligned C99 initializers and being buggy with "try =" (at least with current kernel settings).

> clang-format fs/proc/kcore.c

The 5.7 kernel is out

Posted Jun 1, 2020 14:56 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Alignment is unfortunately one thing it doesn't understand. I've just used `// clang-format off` and `// clang-format on` comments to get it to not see those. But getting `clang-format` to settle formatting disputes saves a lot of time not fiddling around with whitespace arguments. Getting it to do the inverted Christmas tree declaration order would also save iterations for the subsystems that use it.

The 5.7 kernel is out

Posted Jun 1, 2020 15:29 UTC (Mon) by pharm (guest, #22305) [Link] (2 responses)

I bet it thinks try is part of a try .. catch statement. C formatting is not well separated from C++ formatting in clang-format.

The 5.7 kernel is out

Posted Jun 1, 2020 15:47 UTC (Mon) by pharm (guest, #22305) [Link] (1 responses)

Yup. Try switching the variable name from "try" to "try1". I’ve made a bug report: it really shouldn’t regard try as a keyword in C code.

The 5.7 kernel is out

Posted Jun 1, 2020 19:19 UTC (Mon) by pharm (guest, #22305) [Link]

That was quick! Looks like this will hopefully be fixed in the next release of clang-format: https://reviews.llvm.org/D80940

The 5.7 kernel is out

Posted Jun 1, 2020 19:51 UTC (Mon) by josh (subscriber, #17465) [Link]

> carefully aligned C99 initializers

In general, I'm in favor of never attempting to "align" anything other than the current indentation level.

The 5.7 kernel is out

Posted Jun 1, 2020 15:19 UTC (Mon) by kdave (subscriber, #44472) [Link]

Indenting by 1-2 tabs on the next line does not have the problem in general, unlike aligning arguments under the opening "(" still trying to squeeze it under 80 chars.

The 5.7 kernel is out

Posted Jun 1, 2020 16:05 UTC (Mon) by quotemstr (subscriber, #45331) [Link] (20 responses)

The macro magic is another thing I don't like about that code. I think a move to C++ in the kernel is long overdue. If GDB can make the move from metaprogrammed C to C++, so can Linux, and I think the latter's much greater metaprogramming capabilities could really clean up things like ACPI_CAST_INDIRECT_PTR and the trace event declaration stuff.

The 5.7 kernel is out

Posted Jun 1, 2020 17:32 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (15 responses)

The problem is keeping people to using only the "kernel-sensible" parts of C++. There are quite a number of goobers around the stdlib (vector<bool>, unordered_set perf pessimizations, etc.) and the language itself (operator overloading, ADL, etc.) that is unlikely to be allowed beyond RAII and some better typing behaviors.

The 5.7 kernel is out

Posted Jun 1, 2020 20:10 UTC (Mon) by Wol (subscriber, #4433) [Link] (13 responses)

Yup. Simply put, C++ is a high-level language. It is not designed for resource-constrained environments. Modern programmers are not trained for resource-constrained environments.

And resource-constrained is not fixed by throwing level 4 ram at an "insufficient cache in the processor" problem ... :-)

Cheers,
Wol

The 5.7 kernel is out

Posted Jun 1, 2020 20:24 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (4 responses)

There are folks working on standalone contexts for standard C++, but it is in progress and probably won't land everything Linux would likely want/need until C++26. It mostly works by stripping down stdlib features though. You're still stuck with bad language behaviors.

The 5.7 kernel is out

Posted Jun 1, 2020 20:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Some of them DID get fixed, like vector<bool>.

The 5.7 kernel is out

Posted Jun 2, 2020 1:49 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

Do you have a paper number for that?

The 5.7 kernel is out

Posted Jun 2, 2020 2:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I think P1957R2 but I can swear I've seen another one about implicit bool casts.

The 5.7 kernel is out

Posted Jun 2, 2020 2:44 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Those papers do nothing about vector<bool>'s problems:

- auto& item = boolvec[3]; is busted as you get a proxy object instead of a real boolean
- does not work with parallel algorithms (the bits all write to the same byte and collide there)
- T* data = vec.data(); doesn't work in generic code when passed a vector<bool>
- I'm sure there are others

It's just a bad design the standard allows (it's not even required!) that won't get fixed due to ABI guarantees stdlib implementers are basically bound by from the ecosystem. Sure, the standard can tell them to do something, but they can also say "sorry, no can do" (they effectively have a veto on such things because of this).

The paper you refer to is basically about making T* -> bool a warning due to bugs and weird typesystem holes you fall into with the implicit cast floating about your generic code.

The 5.7 kernel is out

Posted Jun 1, 2020 20:37 UTC (Mon) by quotemstr (subscriber, #45331) [Link] (5 responses)

> Yup. Simply put, C++ is a high-level language. It is not designed for resource-constrained environments.

I have to completely disagree with this perspective. C++ lets you control the machine as precisely as C does. There's nothing in the language, nothing at all, that prevents your writing low-level and efficient code. C++ isn't Python. Is your position just that people writing C++ can't avoid the temptation to use inefficient patterns? That's a social problem, not a technical one.

The 5.7 kernel is out

Posted Jun 2, 2020 0:24 UTC (Tue) by Wol (subscriber, #4433) [Link] (3 responses)

There's nothing in the language that prevents you - correct.

But how many programmers actually have a clue about which features are efficient, and which are not? The other massive problem with the question "which features are efficient", is probably that the answer is "it depends on the compiler".

If you *need* a program to be efficient, giving programmers a compiler that can be inefficient may be a social problem, but stopping those programmers from using those features is probably an intractable problem ... I don't want a Ryzen 7 to be the minimum recommended processor for running linux ...

Cheers,
Wol

The 5.7 kernel is out

Posted Jun 2, 2020 0:48 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (2 responses)

The criticisms you mention all apply to C too. I don't see C++ being special here --- to write good code, you have to know what you're doing, and if you're a bozo, you're going to wreck things in either C or C++. That's why we do code review.

The 5.7 kernel is out

Posted Jun 2, 2020 8:21 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

And how much - even kernel code - is code-reviewed? And of those reviewers, how many have the *experience* to know what is good or bad?

You only need some badly written and poorly written driver to start evicting L1 cache and the whole system suffers.

I think it's a case of "C: if it looks efficient it probably is. C++: If it looks efficient, who knows what the hell is going on behind the scenes ..."

Now if you apply C++ discipline to C code that's a whole 'nother ball game!

My expertise is databases. And I like Pick because there is a consistent model right through from hardware to application (at least, there is if the programmer knows what they're doing! :-) Just like C, there's plenty of rope to hang yourself.

Relational - C&D to be precise - is a whole pile of poo. Firstly, there's the logical inconsistency within the rules themselves. Then there's the model second-guessing you to try and protect you from yourself. Then there's the implementation - severely hamstrung by the model itself if it tries to implement it faithfully. Pascal, SQL, C++, ... great for novices, and quite good languages, but expensive in wasted computer power as it tries to protect you from yourself.

Cheers,
Wol

The 5.7 kernel is out

Posted Jun 2, 2020 12:21 UTC (Tue) by adobriyan (guest, #30858) [Link]

Inefficiency of the language can be trivially demonstrated by absence of multiple return values.

Given

int f(const char *str, int *val);

int val;
int rv = f(str, &val);
if (rv < 0)
return rv;
[use "val"]

C ABI and single return value forces to allocate data on a stack and a write.
Now top of stack is optimized so it doesn't matter for performance, but the act of writing to [rsp+] has second order effects.
Stack protector sees that function modifies memory and starts placing canaries, bloating code and issuing reads and adding
mandatory branch for stack smashing.

Could this be solved in C? Yes, by using 2-value structure which fully fits into 2x8-byte registers.
C ABI even has provision for this by referring to RDX as a second return value.
Which of course nobody uses because there is no syntax for destructuring.

The 5.7 kernel is out

Posted Jun 2, 2020 2:04 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Is `-fno-exceptions` really part of C++ or just a mechanism that Linux would have to disable? I guess Linux would have to avoid `new` anyways as it does `malloc`, so maybe it wouldn't be *that* far off. But without `std::optional` and some nice wrapper around `std::variant` to act as Haskell's `Either` or Rust's `Result`, the algorithms aren't that useful. I don't know. At that point, you may as well just adopt some Golang `defer`-like C extension rather than try and strip C++ down since that's mostly what would be wanted from what's left anyways. Sure templates for data structures would be nice, but if what you get is just a bit more rigor than what the macros are already doing, unit tests solve most of that problem too (which you'd want *anyways*).

The 5.7 kernel is out

Posted Jun 1, 2020 20:44 UTC (Mon) by adobriyan (guest, #30858) [Link] (1 responses)

The only noticeable resource constraint is small stack with a warning for every even smaller stack frame.

The 5.7 kernel is out

Posted Jun 2, 2020 0:27 UTC (Tue) by Wol (subscriber, #4433) [Link]

And L1/2/3 cache, and and and ...

Cheers,
Wol

The 5.7 kernel is out

Posted Jun 1, 2020 20:38 UTC (Mon) by adobriyan (guest, #30858) [Link]

> vector<bool>, unordered_set perf pessimizations

This should be fixed by disabling standard library.

> the language itself (operator overloading, ADL, etc.) that is unlikely to be allowed beyond RAII and some better typing behaviors.

This is more than enough. Just check out the horror show called latest incarnation of min()/max() macros.

Kernel was reinventing C++ for quite some time already:
TMP in kfifo.h, macroified bsearch and interval trees (include/linux/interval_tree_generic.h),
function overloading -- grep for __builtin_choose_expr()),
destructors and unique_ptr<>-- devm_alloc_*().

The real losses are compilation slowdown, mangled names and a _lot_ of casts from void * (at least initially).

The 5.7 kernel is out

Posted Jun 2, 2020 7:59 UTC (Tue) by marcthe12 (guest, #135461) [Link] (3 responses)

Kernel space is freestanding code. Lots of stuff will be missing or will be banned. Rust has similar problem. RAII, exceptions, new will not be allowed in the kernel. The only alternative language could be zig but its still no ready yet. Another option will bring kernel code to c11. Alteast generics and bunch C99 feature would reduce some macros. Curious if the is way to request the kernel devs to evaluate Zig, Its perfect time to sponsor or suggest improvement if needed.

The 5.7 kernel is out

Posted Jun 2, 2020 15:44 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

What is it about RAII that would not be allowed? Hiding the explicit dtor call? Not using the STL (or using Rust's `no_std`, maybe even `no_core`) should avoid most heavy dtor calls. You're basically left with the custom ones coded in the project at hand. Then your review is "make sure dtors are cheap" rather than trying to eyeball that the right function call is on every (relevant) exit path. That is, IME, *much* more likely to bitrot over time as other codepaths arise around the relevant codes than someone making a dtor heavier accidentally.

The 5.7 kernel is out

Posted Jun 2, 2020 21:10 UTC (Tue) by excors (subscriber, #95769) [Link] (1 responses)

I assume they meant RTTI, not RAII. RTTI is inefficient and mostly useless. RAII is great, like a more general version of the devm_ API that lets you eliminate large classes of resource-leak bugs with zero overhead.

In a kernel context, "C++" should always be interpreted as "C++ with no exceptions, no RTTI, no STL containers, no std::thread, no new/delete (except for placement new), etc". Issues like std::vector<bool> are irrelevant - any serious embedded developer is always going to implement their own container library to suit their own requirements (like giving the container's owner more control over memory allocation, and not using exceptions to signal errors).

That subset of C++ isn't standardised, but it's widely used (with minor variations) and it's not that hard to stick to. If you don't provide header files for STL containers then nobody will accidentally use them. If you don't define 'operator new' then nobody will accidentally call it instead of your custom memory allocator. A kernel has enough control of its build environment to guarantee those things.

Then you still get useful stuff like RAII, templates, stronger type checking, less reliance on horrific macros, the ability to do automatic refcounting, lambdas, std::unique_ptr, std::atomic, etc. Nothing individually of world-changing importance, but it's a lot of tools that let you design APIs that are easier to use correctly and/or harder to use incorrectly than in C, increasing code quality and avoiding bugs. And you still retain control over every function call and every byte of stack usage when you care about that. And it's a language that millions of programmers are already familiar with (including many already working in resource-constrained environments, and probably a lot of Linux developers who've worked outside the kernel too), and that you can incrementally transition to from C.

The 5.7 kernel is out

Posted Jun 3, 2020 7:10 UTC (Wed) by marcthe12 (guest, #135461) [Link]

True but the point my comment is that the better option is to use an another language that is design for that space. Zig matches that but lets say its still not mature enough

The 5.7 kernel is out

Posted Jun 2, 2020 7:27 UTC (Tue) by zlynx (guest, #2285) [Link] (1 responses)

That's just an example of a terrible indent style. Drop all the arguments to the next line and add only ONE indent level and the problem is solved.

The 5.7 kernel is out

Posted Jun 2, 2020 11:37 UTC (Tue) by neilbrown (subscriber, #359) [Link]

> Drop all the arguments to the next line and add only ONE indent level and the problem is solved.

Yes, and don't run your patch through "checkpatch --strict" - it complains about the line ending with "(".

The 5.7 kernel is out

Posted Jun 5, 2020 5:37 UTC (Fri) by JoePerches (guest, #101448) [Link]

ACPICI uses lindent not humans to format code.
At best, it's ugly.

https://acpica.org/downloads/linux

The Linux version of ACPICA is created from the UNIX release package -- the code is converted to Linux format via an ACPICA utility (AcpiSrc) and lindent.