Scope-based resource management for the kernel
Scope-based resource management for the kernel
Posted Jun 16, 2023 14:51 UTC (Fri) by make (subscriber, #62794)In reply to: Scope-based resource management for the kernel by tialaramex
Parent article: Scope-based resource management for the kernel
You're missing the point. Rust's scope within the Linux kernel is extremely limited (no Rust core code, only a narrow scope of modules/drivers). Rust will not help with the problem that those macros are attempting to solve, because that would require converting all caller locations of those macros to Rust before doing anything else, and that would require converting all their dependencies to Rust, and so on... won't happen.
On the other hand, allowing a C++ (subset) would make all desirable C++ features available everywhere, immediately.
Posted Jun 16, 2023 15:05 UTC (Fri)
by mbunkus (subscriber, #87248)
[Link] (10 responses)
Aren't several of you arguing in this very thread against one of the most iconic & useful C++ feature, RAII? Mostly because it imposes a performance impact (which it does, I don't dispute that; see ibukanov's comment) & isn't as efficient if it requires storing a second copy of a pointer that's already available elsewhere (see vegard's comment)?
Be prepared for resistance, not just from the folks who don't want C++ or don't want language no. 3 in the kernel, but also from those preferring raw speed & space efficiency.
Posted Jun 16, 2023 15:28 UTC (Fri)
by make (subscriber, #62794)
[Link] (2 responses)
Several of "us"? I see nobody arguing against RAII. This whole thread is about adding RAII to the C part of the kernel (implemented with macros and non-standard extensions). RAII already exists in the Rust part of the kernel, it's a standard Rust feature.
> Mostly because it imposes a performance impact
That is not a natural property of RAII. It is possible to use C++ in a way that is less efficient than C, and it is just as possible to use C++ in a way that is more efficient than C, but such comparisons are difficult. In any case, my point is: RAII has no performance impact per se.
(But the more important point is: it is easier to write correct C++ code than to write correct C code.)
> if it requires storing a second copy of a pointer that's already available elsewhere
Sometimes, extra context needs to be stored in the RAII class, that is true. But often, that overhead will be optimized away by the compiler.
I just wrote an example on Godbolt: https://godbolt.org/z/GjsWx1vda - as you see, the machine code is identical, and the whole RAII class gets optimized away; the allocated pointer lives in the same register in both versions, and the size isn't stored anywhere, it remains in the register argument (in both versions).
Writing code where the C++ compiler can optimize away all the RAII "overhead" can be tricky, but even if your compiler is too dumb or your code isn't optimized well enough - optimize later, but have good robust leak-free code from the beginning. Those who really care will get identical machine code, with less effort than writing plain C.
> but also from those preferring raw speed & space efficiency.
That's a myth.
Posted Jun 16, 2023 16:45 UTC (Fri)
by mbunkus (subscriber, #87248)
[Link] (1 responses)
Sorry about the "us"; I was just conflating the different people I was replying to.
OK, maybe "against RAII as commonly used in C++" would be more precise? I was only confused by ibukanov's initial statement that C++'s destructors not allowing arguments. The examples that were given sounded very un-C++-like to me as both cases could easily be solved in the usual C++-RAII style by storing copies of the relevant pointers inside the class. But the arguments against that was "no, bad for performance" (paraphrasing).
I'm really, really not arguing against RAII or against C++ in general, nor against RAII in C++ in particular; quite the opposite. RAII in C++ is one feature I really like about C++. I'm just… confused by what different people wrote.
And about performance: I was referring to std::unique_ptr notbeing a zero-cost abstraction; see Chandler Carruth's presentation about it: https://www.youtube.com/watch?v=rHIkrotSwcc (the most interesting part is probably 17:30–24:00) That falls into the category you've mentioned yourself:
> Writing code where the C++ compiler can optimize away all the RAII "overhead" can be tricky
Posted Jun 16, 2023 17:25 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
For the kernel, yes. Don't forget, if your structures grow in size, you're talking cache misses, cache eviction, cache line bounce, etc. All of which can be VERY expensive.
Cheers,
Posted Jun 17, 2023 7:00 UTC (Sat)
by ibukanov (subscriber, #3942)
[Link] (6 responses)
From a system/emebeded programming point of view I would rather prefer if C++ would require explicit destructor calls for RAII rather than calling destructors automatically. Yes, it will make code more verbose, but at least it will make very obvious what the code is doing. And it will prevent a few bugs due to unexpected destruction of temporaries. For C such enforcement of destructor-type calls will be even more natural that the current attribute hack.
Posted Jun 17, 2023 7:31 UTC (Sat)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
Manual calls to destructors are not RAII. You don't gain any of RAII's advantages by requiring manual calls to free the resource.
Posted Jun 18, 2023 14:46 UTC (Sun)
by ibukanov (subscriber, #3942)
[Link] (1 responses)
Posted Jun 19, 2023 0:32 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link]
Posted Jun 18, 2023 21:13 UTC (Sun)
by nksingh (subscriber, #94354)
[Link] (1 responses)
The advantage of producing the code as needed for review/debugging rather than requiring it to be explicit: when editing, your code remains flexible and modifiable with the compiler doing the bookkeeping at the end, rather than you having to compensate for changes manually before you can even test your code out. I think for domains like embedded, high performance, and kernel code, this transform between 'debuggable' and 'editable' source code would help satisfy both people who want productivity and those who want to know exactly what will happen in the CPU.
Posted Jun 26, 2023 6:13 UTC (Mon)
by ssmith32 (subscriber, #72404)
[Link]
Posted Jul 2, 2023 17:05 UTC (Sun)
by bluss (guest, #47454)
[Link]
Posted Jun 17, 2023 0:09 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (13 responses)
In the C++ fantasy (which Bjarne has been selling for decades) you take any C software, you just rename a few files and bingo, a more capable, more expressive much better language. What are people waiting for?
It's a fantasy, which Linus won't be indulging in his tree. The Linux source code is readily available though, so you can try this out for yourself and make sure not to go talking about this fantasy again until you've actually found out what the reality is like and have something to show for your effort.
Posted Jun 17, 2023 8:15 UTC (Sat)
by make (subscriber, #62794)
[Link] (6 responses)
Sure there's a lot of hate for C++, the language has its many warts and gives you lots of reasons to hate it, and of course people can have different opinions, but your comment bashing it as "fantasy" and asking me to "have something to show" doesn't quite shine a good light on your competence in programming languages.
Long ago, I was a C fanboy and disliked C++, but then came C++11 which solved many of the things I disliked. In the following years, I converted all of my dayjob C projects to C++ and did the same to several open source projects I manage. (Maybe even one you're using.)
My point is: your rather immature request "not to go talking about this fantasy again" is aimed at the wrong guy. I went through this "fantasy", and I've been living in this C++ utopia for many years. It's not fantasy, it works. Of course, it's not all unicorns and rainbows, but strictly better than C in every aspect.
Posted Jun 17, 2023 19:03 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (2 responses)
There speaks the user-space programmer who thinks the solution for a slow program is to throw hardware at it.
Many moons ago, my company was given a six week deadline, and I accepted the challenge to try and meet it. I had five weeks to automate a very manual setup. Four weeks into the project, I estimated my program would take three or four weeks to just run... Oh - and I met the deadline.
That was back in the day when the most powerful weather-forcasting computers had difficulty forcasting the weather before it happened.
Less so now, but as a database programmer I've heard plenty of stories of changes to the Oracle optimiser screwing over carefully crafted and optimised queries.
The kernel programmers have enough trouble fighting C optimisations in gcc - they don't want to have to fight far more obscure optimisations in C++.
How much effort / often times have you had to optimise a program for speed? It's an art that most young people just don't understand.
Cheers,
Posted Jun 17, 2023 19:36 UTC (Sat)
by make (subscriber, #62794)
[Link] (1 responses)
Your whole post sounds awfully arrogant (and wrong). It doesn't add any content to the discussion, you only bash somebody you don't know with bogus and strawman arguments.
Compiler optimizations in C and C++ aren't fundamentally different, and aren't fundamentally different between userspace and kernel space. Yes, there are differences in both aspects, but not in a way that adds to the difficulty like you pretend it does.
> How much effort / often times have you had to optimise a program for speed? It's an art that most young people just don't understand.
Every day for several decades, and I wouldn't call it "art", because it's deterministic and mechanical, the simplest part of my job. Yes, many people don't value fast/lean code, that's a big problem that annoys me a lot, but your way of ranting at me says more about yourself. You sound like "confused old man yells at cloud" rather than "wise old man".
Posted Jun 26, 2023 14:36 UTC (Mon)
by anton (subscriber, #25547)
[Link]
In earlier discussions on the topic, several advocates of these "optimizations" argued that they are very useful for not-quite-source code coming from expanding the original source code (typically when I pointed out that nobody writes programs in a way that the advocate just showed as an example of the usefulness of the "optimization"), and for the same reason that it's not a good idea to warn when the "optimization" strikes (supposedly there is so much not-quite-source code where the "optimization" strikes that one supposedly would be flooded with warnings). Both claims are very doubtful for even the most macro-laden C code, so I assumed the advocates had C++ code in mind; or maybe the advocates were just bullshitting me.
Anyway, I wonder how much the fact that GCC and Clang are written in C++ contributes to adding these kinds of "optimizations" (especially adding them (at first) without a kill switch).
Posted Jun 18, 2023 2:24 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
Posted Jun 19, 2023 11:38 UTC (Mon)
by zorro (subscriber, #45643)
[Link] (1 responses)
Posted Jun 19, 2023 12:32 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jun 17, 2023 20:57 UTC (Sat)
by mss (subscriber, #138799)
[Link] (5 responses)
Posted Jun 17, 2023 21:22 UTC (Sat)
by mb (subscriber, #50428)
[Link] (3 responses)
Posted Jun 17, 2023 22:29 UTC (Sat)
by mss (subscriber, #138799)
[Link] (1 responses)
Posted Jun 18, 2023 12:38 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link]
The remaining C++ proponents continue to believe in a sort of Phlogiston Theory for programming languages. If they can just add the right things to C++ then it will not be an over-complicated language any more. It's true that in C++ 11, C++ 14, C++ 17, C++ 20 and C++ 23 the additions did make the language even more complicated each time, but surely this time it will work.
Posted Jun 18, 2023 6:01 UTC (Sun)
by make (subscriber, #62794)
[Link]
Switching GCC from C to C++ mode alone has no effect on the build time. There are C++ features that do add to the build time, like excessive use of templates, but so do C features like excessive use of macros. It depends on which C++ subset you allow.
I bet there's no build-time difference between Peter's pseudo-RAII using macros and the GNU extensions and "true" C++ RAII (using no other C++ feature).
Posted Jun 17, 2023 23:11 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
It used to be possible to compile Linux with C++ enabled, back in the early 2.6 days. I remember because I worked with a hardware device that had a C++ kernel module.
Then the kernel started using "class" and "operator" as regular variables.
Posted Jun 22, 2023 8:28 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (11 responses)
This is the main issue: define "subset" and "desirable".
Another top problem is: "C++ is not hard, your developers are just holding it wrong". I've called this the "mythical workplace" argument.
Posted Jun 22, 2023 9:24 UTC (Thu)
by make (subscriber, #62794)
[Link] (10 responses)
If that's your main issue, then luckily it's a non-issue.
The premise of the article is that the kernel developers have already decided they want (something like) RAII, and my point is that for this feature, C++ is a better tool than C with non-standard extensions.
Discussions which C++ features are allowed in the kernel is no different than any other coding style discussion. There are already discussions on which C standard shall be used and which new C standard features are acceptable in the kernel (like atomics). Nothing new here, just more of the usual.
> Another top problem is: "C++ is not hard, your developers are just holding it wrong".
That's a straw man. Let's discuss the language rather than discussing theoretical arguments from hypothetical C++ fanboys, because that's not relevant for the language choice.
About C++: I know very well that C++ is hard, and I admit it's a complex mess of a language. Many reasonable things can be said about the ugliness of C++.
If you're starting with C, and you want to use certain advanced features like RAII, C++ is a good choice, because the migration is so simple. It is certainly reasonable to say Rust is better than C++, and I don't argue C++ should be used *instead* of Rust - I only say C++ could easily be used *now* to improve code quality where a Rust migration is not possible currently. Additionally, a future rewrite to Rust is easier from C++ with RAII than from plain C, because the source code flow in C++ and Rust is similar. C++ is actually a good intermediate language for a smoother migration to Rust.
Posted Jun 22, 2023 10:32 UTC (Thu)
by mb (subscriber, #50428)
[Link] (8 responses)
No, not at all.
It does not work to say that we're going to switch to C++ but only use RAII from it.
It's better to keep that huge amount of stuff out of the kernel to begin with.
Posted Jun 22, 2023 18:38 UTC (Thu)
by make (subscriber, #62794)
[Link] (7 responses)
You're missing the point. The article and this thread is about using RAII in the Linux kernel, not about inheritance. RAII works the same in C++ and Rust (and in C with GNU extensions, as it's going to be used soon).
The fact that C++ has features that Rust has not (which I didn't suggest to use and which do not affect the code flow) does not falsify my argument - it doesn't even have anything to do with this thread.
> It does not work to say that we're going to switch to C++ but only use RAII from it.
It works with other C language features or Rust language features or coding style policies or anything else. What makes you think policies about acceptable C++ features are different? Just because of "arguing over and over again"? Why is arguing over C++ features different? Bikeshedding discussions have existed as long as Linux exists, and will always exist. This argument seems rather arbitrary, because you can use the same argument to reject C11, C17, Rust (or anything else).
> The C implementation might not be as pretty as C++
Agree. We don't agree on the rest, but that's fine.
Posted Jun 22, 2023 18:55 UTC (Thu)
by mb (subscriber, #50428)
[Link] (6 responses)
No. But you didn't read my full text, before answering on the first paragraph.
>What makes you think policies about acceptable C++ features are different?
So you really think that inheritance and virtual functions would not be one of the first next C++ features that people would demand, if we would compile the kernel with a C++ compiler?
Converting all manual implementations of virtual function calls is the next obvious transistion we would have.
Posted Jun 22, 2023 19:07 UTC (Thu)
by make (subscriber, #62794)
[Link] (3 responses)
Oh yes, you were missing the point, because instead of replying to the point I made (about RAII), you made up a new story and replied to this story of yours.
Now you came up with a new story, this time about virtual functions, only to prove that code flow in C++ and Rust is different after all, but that again misses my point. Don't you get it? This article and this thread is about RAII and nothing else.
Posted Jun 22, 2023 19:19 UTC (Thu)
by mb (subscriber, #50428)
[Link] (2 responses)
Nice that you agree.
Posted Jun 22, 2023 19:35 UTC (Thu)
by make (subscriber, #62794)
[Link] (1 responses)
No, I don't agree. Virtual functions don't affect the code flow; they are just syntactic sugar for dynamic dispatch, but the code flow is the same as with other ways of doing dynamic dispatch (no matter if C++, C or Rust). But, uh, we're now even more off-topic, you're dragging me away from the topic (=RAII) so much, that I'm confident you're just a troll, and I've already been feeding you too much, shame on me. That was unexpected on LWN.
Posted Jun 22, 2023 19:41 UTC (Thu)
by mb (subscriber, #50428)
[Link]
No it isn't.
Posted Jun 22, 2023 20:51 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
Of course it would; implementing classes in C is not fun at all and it's done all over the kernel already: https://lwn.net/Articles/444910/
BTW I suspect this is another reason people want to keep C++ out: Object-Oriented Obfuscation. There are some problems to which object-orientation maps well but C++ went really "all-in" and kept functional programming techniques out of developers' mindsets for much too long of a time, holding back the entire industry for decades.
Funny how Javascript out of all languages helped functional programming finally break out.
Rust is of course more functional than OO.
Posted Jun 22, 2023 21:02 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Forgot the mandatory reference to the masterpiece, sorry for the extra email:
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
Yes this one is not about C++ but Java which is even worse. But: close enough.
Posted Jun 22, 2023 20:42 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Not "mine"; the issue of everyone who does not want C++
> then luckily it's a non-issue.
Must feel good to be right when so many people are wrong :-)
> my point is that for this feature, C++ is a better tool than C with non-standard extensions.
Yes! But: see above.
> Discussions which C++ features are allowed in the kernel is no different than any other coding style discussion.
Qualitatively yes. Quantitatively no. I know: I don't have any metrics to show you; these things are very hard to measure. But you don't have any either and the consensus / educated guess in Linux (and some other projects) is that the trade-off is not worth it. That is of course based on observations in other, actual C++ projects, I mean the lack of metrics does not mean it's based on thin air either.
BTW: which features are allowed is IMHO a small part of code style discussions. A very important part of course, maybe the most important one but small in "email volume". I'm just saying "code style" is not a great choice of words here, never mind.
> That's a straw man. Let's discuss the language rather than discussing theoretical arguments from hypothetical C++ fanboys
Oh come on: "you're holding it wrong" is the typical answer of _every_, _real_ C++ fanboy! Very vocal and hopefully not representative as usual on the Internet but certainly not "hypothetical".
> I know very well that C++ is hard, and I admit it's a complex mess of a language.
Thank you!
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Wol
Scope-based resource management for the kernel
Scope-based resource management for the kernel
resource ends.
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Wol
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Compiler optimizations in C and C++ aren't fundamentally different
My impression is that they are, and that the pretence that programs do not exercise standard-undefined behaviour comes, for a large part, from C++ programmers, while those who use options like -fno-strict-aliasing to get rid of "optimizations" that are based on this pretence are, for a large part, C programmers.
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Bringing up C++ when it is never going to be used in the Linux kernel adds nothing to the discussion in the first place.
Scope-based resource management for the kernel
The Linux source code is readily available though, so you can try this out for yourself and make sure not to go talking about this fantasy again until you've actually found out what the reality is like and have something to show for your effort.
There has been a few patch sets posted to allow C++ usage in the Linux kernel - the most recent one AFAIK was posted as an April Fools' joke 5 years ago.
Although, given the well-known upstream hostility to C++, people find it hard to justify the amount of work required to prepare a serious RFC.
Scope-based resource management for the kernel
It's just that the advantages of using C++ are not seen by kernel developers as being significant enough to justify the downsides of having C++. (e.g. much longer build time).
Scope-based resource management for the kernel
There is no hostility.
Expressions like C++ is a horrible language
or the crap that is C++
or (more recent) It really is a crap language
certainly sound like hostility.
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Everyone will have different answers (and C++ has everyone's favorite features).
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Rust has no inheritance. Code flows between ideomatic C++ and ideomatic Rust are quite different.
People *will* start using more and more of C++'s features.
The C implementation might not be as pretty as C++, but pulling in C++ comes with a tremendous cost of arguing over and over again why this and that C++ feature shall not be used in the kernel.
Scope-based resource management for the kernel
Scope-based resource management for the kernel
And there goes your same code flow.
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel
Scope-based resource management for the kernel