8 ms·

"And finally, you’ll need to know at least some C. The C++ runtime is far too large for the kernel, so writing bare metal C is essential." That line reminded m

"And finally, you’ll need to know at least some C. The C++ runtime is far too large for the kernel, so writing bare metal C is essential." That line reminded me that NetBSD added Lua for writing kernel modules. (https://news.ycombinator.com/item?id=6562611 https://news.ycombinator.com/item?id=6562611) Anybody have any experiences to share from this?

sigjuice 9y ago
If you look at the NetBSD kernel source https://github.com/NetBSD/src.git https://github.com/NetBSD/src.git, it doesn't look like there are any real and substantial Lua kernel modules. $ find sys -name '*.lua' sys/modules/examples/luahello/luahello.lua sys/modules/examples/luareadhappy/happy.lua sys/modules/lua/infinite.lua sys/modules/lua/test.lua sys/modules/luasystm/test.lua
alxlaz 9y ago
There are plenty of operating systems that use C++ on the kernel side of things. Some things, like exceptions, are frowned upon and rarely used -- if at all -- but there is no shortage of C++ kernel code. Just not in Linux. When it comes to Linux, one could say that most reasons to avoid it are historical, but this does not quite paint the awkward truth -- namely that, for most of the kernel's lifetime (since back in 1991), C++ compilers simply did not have the level of maturity and stability across the breadth of platforms that Linux required. Linus Torvalds' stance on this matter is pretty well-known: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus . Today, when x86-64 and ARM are the only two families that you need to care about in the following ten years or so (maybe RISC-V but I rather doubt it), it probably makes sense to look at C++ for operating systems work, but the runtime is certainly heavier than back when Linus was writing about it, too. A modern C++ compiler has a lot of baggage; C++ was huge back in 1998, now it's bloody massive. IMHO, all the reasons why you would want to use C++ (templating support without resorting to strange hacks, useful pointer semantics and so on) are reasonably well-served by cleaner languages with less hefty runtimes, like Rust. What these alternatives do lack is the amazing level of commercial support that C++ has.
- jcelerier 9y ago
  > C++ was huge back in 1998, now it's bloody massive. I don't think any "run-time" feature was added since, though. It's all either OS support (<thread>, etc, that you wouldn't use in-kernel anyways) or template stuff that has 0 impact on runtime (and actually sometimes helps decreasing code size). https://istarc.wordpress.com/2014/07/18/stm32f4-oop-with-embedded-systems/ https://istarc.wordpress.com/2014/07/18/stm32f4-oop-with-emb... https://www.embedded.com/design/programming-languages-and-tools/4438660/Modern-C--in-embedded-systems---Part-1--Myth-and-Reality https://www.embedded.com/design/programming-languages-and-to... https://hackaday.com/2015/12/18/code-craft-embedding-c-templates/ https://hackaday.com/2015/12/18/code-craft-embedding-c-templ... If some guys are able to run c++ on 8kb microcontrollers, there's hardly a non-political reason it couldn't be used in-kernel. See also IncludeOS: http://www.includeos.org/ http://www.includeos.org/
  - alxlaz 9y ago
    Additions have certainly been made since back in 1998 (things like smart pointers are relatively new on this scale, as far as I know). Many runtimes for resource-constrained embedded systems do not support all of C++'s features. Exceptions are the most usual omission. You can certainly strip things down to a subset that can fit 128K of flash and need only 1 or 2K of RAM at runtime, but the question is not only one of computational resources used for the library itself. Additional code always means additional bugs, the semantics sometimes "hide" memory copying or dynamic allocation in ways that many C++ programmers do not understand (and the ones who do are more expensive to hire than the ones who do not), and so on. You can certainly avoid these things and use C++, but you can also avoid them by using C. I agree that mistrust and politics definitely play the dominating role in this affair though. I have seen good, solid, well-performing C++ code. I prefer C, but largely due to a vicious circle effect -- C is the more common choice, so I wrote more C code, so I know C better, so unless I have a good reason to recommend or write C++ instead of C, I will recommend or write C instead. I do think (possibly for the same reason) that it is harder to write correct C++ code than it is to write correct C code, but people have sent things to the Moon and back using assembly language for very weird machines, so clearly there are valid trade-offs that can be made and which include using language far quirkier than C++.
revelation 9y ago
There is plenty of C++ in the Linux kernel. It just masquerades as function pointers and initial fields in structures called "base".
- TFortunato 9y ago
  Your getting downvoted, but you are kind-of correct. Even if it isn't actually written in C++, there is a lot of "OO-style" code in the kernel that does things like dynamic disoatch using VTables...basically making explicit what C++ is going to do behind the scenes for you anyways. I can see the argument from Linus' POV about avoiding over abstraction, and knowing exactly what your code is doing on a low-level, but at the same time it leads to a lot of reinventing the wheel and makes me think there is a better balance to be found. https://lwn.net/Articles/444910/ https://lwn.net/Articles/444910/ https://lwn.net/Articles/446317/ https://lwn.net/Articles/446317/
  - madez 9y ago
    It doesn't only make you think there is a better balance, it also makes you think harder whether the task at hand needs this kind of complexity. If this is all hidden under abstraction, developers might not care enough.
    - TFortunato 9y ago
      I absolutely agree with you on the dangers of overabstracting / hiding too much detail. That said, I do wonder if things have changed, since Linus's c++ "rant" re: the type of developers who would choose to work on kernel code in c++. I do remember a time when learning c++ was very much in popular, before the "in" language moved to java, to python, to JS, etc., so there may have been more of a problem with inexperienced coders back then than there is now. (I have no idea if this is true at all, just curious!) I'm addressing this as someone who has done C++ work on very small embedded systems (e.g. microcontrollers with no external memory) including RTOS code and low-latency control loops, and there were definitely some nice features in C++ that can save you some time and lines of code without adding a bunch of needless overhead. Of course, there was a learning curve when bringing new people on board the project about what was/wasn't allowed for performance reasons. In general though, I see no reason why there couldn't be some subset of C++ used for kernel development other than Linus' / the kernel dev community's general distaste for it.
albinofrenchy 9y ago
The C++ runtime is too big for the kernel. It is also largely unnecessary. You can easily compile C++ code without STL or larger library support. This still leaves some holes that the runtime provides, but all of which are easy to provide -- namely things like 'new' and 'delete'.
chowyuncat 9y ago
At work we write plenty of C++ for kernel modules, but with the caveat that our C++ can rarely include a Linux kernel header directly. We have to write a small shim for every kernel function we consume. No library runtime features, so no RTTI or exceptions, but we use templates and dynamic dispatch.
feelin_googley 9y ago
"Anybody have any experiences to share from this?" http://lua-users.org/wiki/MarcBalmer http://lua-users.org/wiki/MarcBalmer
pag 9y ago
I created a linux kernel dynamic binary translator [1] (think of it as being like an in-situ vmware esxi) using C++. The key was to not use anything that touches floating point. Mostly what I wanted was templates, atomics, and a few other nicities. Recently I got granary working on the 4.4.0 kernel (after a few manual tweaks here and there to the kernel source code and to some of granary's auto-generated files). [1] https://github.com/Granary/granary https://github.com/Granary/granary
josteink 9y ago
> "And finally, you’ll need to know at least some C. The C++ runtime is far too large for the kernel, so writing bare metal C is essential." And here I was about to ask if anyone has a similar article based on Rust :)
lmilcin 9y ago
It is my understanding that there is no technical reason but rather a personal preference of Linus to continue working with plain C. I did some kernel development (mainly some drivers) and I am also doing a lot of embedded development (credit card terminals, personal projects for ARM Cortex-M) I must say that I am happy with this choice. The kernel is complex enough and you want to focus on understanding what really matters without being distracted by arcane constructs that would inevitably come with C++. My experience with C++ guys is that there will inevitably be a population of smart developers which will try to be "smart" with the language which typically ends up with everybody else spending more time on understanding what is happening than the time that was actually saved by the construct. C does not pose that problem. C is simple and there is relatively little occasion to be very smart with it, which is a good thing, IMHO.

sigjuice 9y ago

If you look at the NetBSD kernel source https://github.com/NetBSD/src.git https://github.com/NetBSD/src.git, it doesn't look like there are any real and substantial Lua kernel modules. $ find sys -name '*.lua' sys/modules/examples/luahello/luahello.lua sys/modules/examples/luareadhappy/happy.lua sys/modules/lua/infinite.lua sys/modules/lua/test.lua sys/modules/luasystm/test.lua

alxlaz 9y ago

There are plenty of operating systems that use C++ on the kernel side of things. Some things, like exceptions, are frowned upon and rarely used -- if at all -- but there is no shortage of C++ kernel code. Just not in Linux. When it comes to Linux, one could say that most reasons to avoid it are historical, but this does not quite paint the awkward truth -- namely that, for most of the kernel's lifetime (since back in 1991), C++ compilers simply did not have the level of maturity and stability across the breadth of platforms that Linux required. Linus Torvalds' stance on this matter is pretty well-known: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus . Today, when x86-64 and ARM are the only two families that you need to care about in the following ten years or so (maybe RISC-V but I rather doubt it), it probably makes sense to look at C++ for operating systems work, but the runtime is certainly heavier than back when Linus was writing about it, too. A modern C++ compiler has a lot of baggage; C++ was huge back in 1998, now it's bloody massive. IMHO, all the reasons why you would want to use C++ (templating support without resorting to strange hacks, useful pointer semantics and so on) are reasonably well-served by cleaner languages with less hefty runtimes, like Rust. What these alternatives do lack is the amazing level of commercial support that C++ has.

jcelerier 9y ago
> C++ was huge back in 1998, now it's bloody massive. I don't think any "run-time" feature was added since, though. It's all either OS support (<thread>, etc, that you wouldn't use in-kernel anyways) or template stuff that has 0 impact on runtime (and actually sometimes helps decreasing code size). https://istarc.wordpress.com/2014/07/18/stm32f4-oop-with-embedded-systems/ https://istarc.wordpress.com/2014/07/18/stm32f4-oop-with-emb... https://www.embedded.com/design/programming-languages-and-tools/4438660/Modern-C--in-embedded-systems---Part-1--Myth-and-Reality https://www.embedded.com/design/programming-languages-and-to... https://hackaday.com/2015/12/18/code-craft-embedding-c-templates/ https://hackaday.com/2015/12/18/code-craft-embedding-c-templ... If some guys are able to run c++ on 8kb microcontrollers, there's hardly a non-political reason it couldn't be used in-kernel. See also IncludeOS: http://www.includeos.org/ http://www.includeos.org/
- alxlaz 9y ago
  Additions have certainly been made since back in 1998 (things like smart pointers are relatively new on this scale, as far as I know). Many runtimes for resource-constrained embedded systems do not support all of C++'s features. Exceptions are the most usual omission. You can certainly strip things down to a subset that can fit 128K of flash and need only 1 or 2K of RAM at runtime, but the question is not only one of computational resources used for the library itself. Additional code always means additional bugs, the semantics sometimes "hide" memory copying or dynamic allocation in ways that many C++ programmers do not understand (and the ones who do are more expensive to hire than the ones who do not), and so on. You can certainly avoid these things and use C++, but you can also avoid them by using C. I agree that mistrust and politics definitely play the dominating role in this affair though. I have seen good, solid, well-performing C++ code. I prefer C, but largely due to a vicious circle effect -- C is the more common choice, so I wrote more C code, so I know C better, so unless I have a good reason to recommend or write C++ instead of C, I will recommend or write C instead. I do think (possibly for the same reason) that it is harder to write correct C++ code than it is to write correct C code, but people have sent things to the Moon and back using assembly language for very weird machines, so clearly there are valid trade-offs that can be made and which include using language far quirkier than C++.

revelation 9y ago

There is plenty of C++ in the Linux kernel. It just masquerades as function pointers and initial fields in structures called "base".

TFortunato 9y ago
Your getting downvoted, but you are kind-of correct. Even if it isn't actually written in C++, there is a lot of "OO-style" code in the kernel that does things like dynamic disoatch using VTables...basically making explicit what C++ is going to do behind the scenes for you anyways. I can see the argument from Linus' POV about avoiding over abstraction, and knowing exactly what your code is doing on a low-level, but at the same time it leads to a lot of reinventing the wheel and makes me think there is a better balance to be found. https://lwn.net/Articles/444910/ https://lwn.net/Articles/444910/ https://lwn.net/Articles/446317/ https://lwn.net/Articles/446317/
- madez 9y ago
  It doesn't only make you think there is a better balance, it also makes you think harder whether the task at hand needs this kind of complexity. If this is all hidden under abstraction, developers might not care enough.
  - TFortunato 9y ago
    I absolutely agree with you on the dangers of overabstracting / hiding too much detail. That said, I do wonder if things have changed, since Linus's c++ "rant" re: the type of developers who would choose to work on kernel code in c++. I do remember a time when learning c++ was very much in popular, before the "in" language moved to java, to python, to JS, etc., so there may have been more of a problem with inexperienced coders back then than there is now. (I have no idea if this is true at all, just curious!) I'm addressing this as someone who has done C++ work on very small embedded systems (e.g. microcontrollers with no external memory) including RTOS code and low-latency control loops, and there were definitely some nice features in C++ that can save you some time and lines of code without adding a bunch of needless overhead. Of course, there was a learning curve when bringing new people on board the project about what was/wasn't allowed for performance reasons. In general though, I see no reason why there couldn't be some subset of C++ used for kernel development other than Linus' / the kernel dev community's general distaste for it.

albinofrenchy 9y ago

The C++ runtime is too big for the kernel. It is also largely unnecessary. You can easily compile C++ code without STL or larger library support. This still leaves some holes that the runtime provides, but all of which are easy to provide -- namely things like 'new' and 'delete'.

chowyuncat 9y ago

At work we write plenty of C++ for kernel modules, but with the caveat that our C++ can rarely include a Linux kernel header directly. We have to write a small shim for every kernel function we consume. No library runtime features, so no RTTI or exceptions, but we use templates and dynamic dispatch.

feelin_googley 9y ago

"Anybody have any experiences to share from this?" http://lua-users.org/wiki/MarcBalmer http://lua-users.org/wiki/MarcBalmer

pag 9y ago

I created a linux kernel dynamic binary translator [1] (think of it as being like an in-situ vmware esxi) using C++. The key was to not use anything that touches floating point. Mostly what I wanted was templates, atomics, and a few other nicities. Recently I got granary working on the 4.4.0 kernel (after a few manual tweaks here and there to the kernel source code and to some of granary's auto-generated files). [1] https://github.com/Granary/granary https://github.com/Granary/granary

josteink 9y ago

> "And finally, you’ll need to know at least some C. The C++ runtime is far too large for the kernel, so writing bare metal C is essential." And here I was about to ask if anyone has a similar article based on Rust :)

lmilcin 9y ago

It is my understanding that there is no technical reason but rather a personal preference of Linus to continue working with plain C. I did some kernel development (mainly some drivers) and I am also doing a lot of embedded development (credit card terminals, personal projects for ARM Cortex-M) I must say that I am happy with this choice. The kernel is complex enough and you want to focus on understanding what really matters without being distracted by arcane constructs that would inevitably come with C++. My experience with C++ guys is that there will inevitably be a population of smart developers which will try to be "smart" with the language which typically ends up with everybody else spending more time on understanding what is happening than the time that was actually saved by the construct. C does not pose that problem. C is simple and there is relatively little occasion to be very smart with it, which is a good thing, IMHO.