4 ms·

Running any code in the CPU's most privileged ring, regardless of language, is going to give you access to directly programming the MMU, scheduling processes ac

Running any code in the CPU's most privileged ring, regardless of language, is going to give you access to directly programming the MMU, scheduling processes across multiple CPU's, control over caches to a fairly large extent, and the ability to control every device in the system. A large amount of this is achieved by bit-banging otherwise inaccessible registers in the CPU itself via assembly (ie. in the case of the MMU, GDT and IDT for x86), or via MMIO for modern busses/devices. The language doesn't necessarily "need" to have a complex model of the entire physical machine to be able to achieve all of those things. How much closer to the metal do you want to be? You really want your programming language to have innate constructs for directly controlling the baggage the x86 CPU (or any other for that matter) brings with it? I don't. You also want kernel code to be performant (ie. compiled by a decently optimizing compiler, of which there are many for C), allow you to disable garbage collection or be totally free of it so you can explicitly manage separate pools of memory. C ticks all those boxes which is why its still the most dominant and widespread language for OS kernel development nearly half a century since UNIX was first rewritten in C, and will be for years to come, like it or loathe it, and despite there being much more modern contenders (eg. Rust) which don't have the momentum yet.

pjmlp 7y ago
C doesn't tick any box regarding: - vector execution units - out of order execution - delay slots - L1 and L2 explicit cache access - MMU access - register windows - gpgpu All of that is given access by Assembly opcodes, not C specific language features. And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language with compiler intrinsics was done 10 years before C existed and is still being sold by Unisys. The only thing that C has going for it are religious embedded devs that won't touch anything else other than C89 (yep not even C99), or FOSS UNIX clones. And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences.
- nineteen999 7y ago
  Which modern, portable language gives you direct control over the MMU, out of order execution, delay slots and explicit cache access, other than hardware specific assembler? None that I know of can do this in a hardware agnostic way. Do tell. I clearly mentioned that assembler was required for much of this, where components aren't programmed by MMIO. This would be the same regardless of whether you used Rust, Go, or FORTRAN77 to write your kernel. I'm not even going to bother with your security comments, we all agree by now. There are plenty of people using C99 in embedded at least in userspace, even the Linux kernel uses some C99 extensions (eg. --std=gnu89 with gcc), and those FOSS UNIX clones have taken over the planet at this point in terms of smartphone adoption, data center servers etc. Despite the obvious flaws, this is still a better world to live in than Microsoft's proposed monoculture of the 1990's.
  - pjmlp 7y ago
    None, including C, which makes it nothing special. Any compiled language can call into Assembly. The phones I know as having taken over the world run on C++, Objective-C, Swift, Java, with very little C still left around, and with its area being reduced with each OS release. As for data centers, there is a certain irony that on Azure those FOSS run on top of Hyper-V, written in C++, on Google Cloud run on top of gVisor written in Go, on Amazon on top of Firecracker written in Rust, and on ChromeOS containers written in a mix of Go/Rust.
    - nineteen999 7y ago
      > Any compiled language can call into Assembly. So ... you're repeating what I already said. Android -> Linux -> mostly C, and assembly IOS -> Darwin -> XNU -> C/C++, and assembly Hyper-V runs as a Windows Server role. Windows kernel is C, and assembly gVisor runs on Linux -> C, assembly Firecracker runs on KVM, which runs on Linux -> C, assembly In every single thing you have listed, the closest thing to the "bare metal" is C, and assembly. THAT's what makes C special. Its level of adoption, ubiquity and accessibility. Not its spectacular lack of security risks. Anyway, you have come a very long way from where the parent poster started which was: Most of the stuff people think of as being the "metal" in C are, in many cases, virtual abstractions created by the operating system. To which I merely pointed out, on the other side of the interface layer is, most commonly C. And assembly. Operating Systems design has to and is obviously evolving away from this. I disagree that we have reached "peak C" and that is going to decline before it gets bigger. Unfortunately pjmlp many of the conversations we have start this way, and devolve into this. I don't think I'm going to bother again. I think one (or both) of us will just have to agree to disagree. Have a nice day.
- jstimpfle 7y ago
  > And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences. In the meantime, did you find a memory leak in my code? https://news.ycombinator.com/item?id=21275440 https://news.ycombinator.com/item?id=21275440 Not that I want to vehemently disagree with your security statements, but I think I'd love to have a little bit more "show" and less "tell". That also applies to showing practicality of managed languages, practicality of 90's business software development (C++/COM), practicality of dead commercial languages (Delphi + VCL). Giving just endless lists of ancient buzzwords doesn't help.
  - pjmlp 7y ago
    It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? Regarding show, don't tell. The 21st century React Native for Windows is written on top of COM/C++, https://github.com/microsoft/react-native-windows https://github.com/microsoft/react-native-windows https://www.youtube.com/watch?v=IUMWFExtDSg https://www.youtube.com/watch?v=IUMWFExtDSg We are having a Delphi conference in upcoming weeks, https://entwickler-konferenz.de/ https://entwickler-konferenz.de/, and it gets regularly featured on the German press, https://www.dotnetpro.de/delphi-959606.html https://www.dotnetpro.de/delphi-959606.html.
    - jstimpfle 7y ago
      > It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? I was thinking you'd look at it before writing your next 25 comments, but it seems I was wrong. So I'll just wait, it's fine. > The 21st century React Native for Windows is written on top of COM/C++ From a skim I could find exactly zero mentions of COM/C++ stuff in there. Sure, this RN might sit on a pile of stuff that has COM buried underneath. That doesn't mean that COM is a necessity to do this React stuff, and not even that it's a good design from a developer's perspective. You give zero ideas what's a good idea about COM. Just buzzwords and links to stuff and more stuff, with no relation obvious to me. If you actually have to go through the whole COM boilerplate and the abominations to build a project with COM, just to connect to a service, because some people thought it wasn't necessary to provide a simple API (connect()/disconnect()/read_next_event()) then the whole thing isn't so funny anymore.

pjmlp 7y ago

C doesn't tick any box regarding: - vector execution units - out of order execution - delay slots - L1 and L2 explicit cache access - MMU access - register windows - gpgpu All of that is given access by Assembly opcodes, not C specific language features. And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language with compiler intrinsics was done 10 years before C existed and is still being sold by Unisys. The only thing that C has going for it are religious embedded devs that won't touch anything else other than C89 (yep not even C99), or FOSS UNIX clones. And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences.

nineteen999 7y ago
Which modern, portable language gives you direct control over the MMU, out of order execution, delay slots and explicit cache access, other than hardware specific assembler? None that I know of can do this in a hardware agnostic way. Do tell. I clearly mentioned that assembler was required for much of this, where components aren't programmed by MMIO. This would be the same regardless of whether you used Rust, Go, or FORTRAN77 to write your kernel. I'm not even going to bother with your security comments, we all agree by now. There are plenty of people using C99 in embedded at least in userspace, even the Linux kernel uses some C99 extensions (eg. --std=gnu89 with gcc), and those FOSS UNIX clones have taken over the planet at this point in terms of smartphone adoption, data center servers etc. Despite the obvious flaws, this is still a better world to live in than Microsoft's proposed monoculture of the 1990's.
- pjmlp 7y ago
  None, including C, which makes it nothing special. Any compiled language can call into Assembly. The phones I know as having taken over the world run on C++, Objective-C, Swift, Java, with very little C still left around, and with its area being reduced with each OS release. As for data centers, there is a certain irony that on Azure those FOSS run on top of Hyper-V, written in C++, on Google Cloud run on top of gVisor written in Go, on Amazon on top of Firecracker written in Rust, and on ChromeOS containers written in a mix of Go/Rust.
  - nineteen999 7y ago
    > Any compiled language can call into Assembly. So ... you're repeating what I already said. Android -> Linux -> mostly C, and assembly IOS -> Darwin -> XNU -> C/C++, and assembly Hyper-V runs as a Windows Server role. Windows kernel is C, and assembly gVisor runs on Linux -> C, assembly Firecracker runs on KVM, which runs on Linux -> C, assembly In every single thing you have listed, the closest thing to the "bare metal" is C, and assembly. THAT's what makes C special. Its level of adoption, ubiquity and accessibility. Not its spectacular lack of security risks. Anyway, you have come a very long way from where the parent poster started which was: Most of the stuff people think of as being the "metal" in C are, in many cases, virtual abstractions created by the operating system. To which I merely pointed out, on the other side of the interface layer is, most commonly C. And assembly. Operating Systems design has to and is obviously evolving away from this. I disagree that we have reached "peak C" and that is going to decline before it gets bigger. Unfortunately pjmlp many of the conversations we have start this way, and devolve into this. I don't think I'm going to bother again. I think one (or both) of us will just have to agree to disagree. Have a nice day.
jstimpfle 7y ago
> And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences. In the meantime, did you find a memory leak in my code? https://news.ycombinator.com/item?id=21275440 https://news.ycombinator.com/item?id=21275440 Not that I want to vehemently disagree with your security statements, but I think I'd love to have a little bit more "show" and less "tell". That also applies to showing practicality of managed languages, practicality of 90's business software development (C++/COM), practicality of dead commercial languages (Delphi + VCL). Giving just endless lists of ancient buzzwords doesn't help.
- pjmlp 7y ago
  It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? Regarding show, don't tell. The 21st century React Native for Windows is written on top of COM/C++, https://github.com/microsoft/react-native-windows https://github.com/microsoft/react-native-windows https://www.youtube.com/watch?v=IUMWFExtDSg https://www.youtube.com/watch?v=IUMWFExtDSg We are having a Delphi conference in upcoming weeks, https://entwickler-konferenz.de/ https://entwickler-konferenz.de/, and it gets regularly featured on the German press, https://www.dotnetpro.de/delphi-959606.html https://www.dotnetpro.de/delphi-959606.html.
  - jstimpfle 7y ago
    > It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? I was thinking you'd look at it before writing your next 25 comments, but it seems I was wrong. So I'll just wait, it's fine. > The 21st century React Native for Windows is written on top of COM/C++ From a skim I could find exactly zero mentions of COM/C++ stuff in there. Sure, this RN might sit on a pile of stuff that has COM buried underneath. That doesn't mean that COM is a necessity to do this React stuff, and not even that it's a good design from a developer's perspective. You give zero ideas what's a good idea about COM. Just buzzwords and links to stuff and more stuff, with no relation obvious to me. If you actually have to go through the whole COM boilerplate and the abominations to build a project with COM, just to connect to a service, because some people thought it wasn't necessary to provide a simple API (connect()/disconnect()/read_next_event()) then the whole thing isn't so funny anymore.