6 ms·

One thing I've wondered for some time is why don't the Linux developers modify the compiler to suit their needs better. At that project scale, wouldn't it star

One thing I've wondered for some time is why don't the Linux developers modify the compiler to suit their needs better. At that project scale, wouldn't it start making sense to start solving problems like "If it were possible to write a list-traversal macro that could declare its own iterator [...]" by adding the functionality you want to GCC?

deleted 5y ago
[deleted]
na85 5y ago
I'm not a compiler expert here but when clang was new and one of the BSD distros was making a lot of hay about moving to it, I remember one of the arguments in favor being that the GCC codebase is a mess and not easily extended.
Jtsummers 5y ago
That would make the code (and the compiler) non-C89 compliant. At which point, why not move to a different standard rather than bork both the kernel and the compiler if it can meet the needs better?
- electroly 5y ago
  The Linux kernel requires GNU extensions; it's already not ANSI C89.
  - deleted 5y ago
    [deleted]
  - Jtsummers 5y ago
    Alright, making it more non-compliant, then. Still creates problems for everyone and also necessitates a larger jump in the GCC version to support (unless you're going to back port the new extensions to every version that the kernel currently works with). Currently you can compile the Linux kernel with GCC 5.1. If you changed the compiler to support this one feature (or any other) you'd either need to back port it several versions (potentially back to 5) or abandon all of them. Which is probably a no-go with a project that's overall as conservative as the Linux kernel project.
initplus 5y ago
Maybe that's helpful today, but by remaining (relatively) standards compliant the kernel codebase has a more long-term resiliency. The more tightly wedded to a single compiler implementation the greater the long term risk for the project. If some shenanigans were to happen upstream in GCC it would not be the end of Linux.
- colejohnson66 5y ago
  But they're not standards compliant. They rely on many GCC extensions that make compiling on something else not possible.
  - tinalumfoil 5y ago
    Other compilers support GCC extensions. > The Linux kernel has always traditionally been compiled with GNU toolchains such as GCC and binutils. Ongoing work has allowed for Clang and LLVM utilities to be used as viable substitutes. Distributions such as Android, ChromeOS, and OpenMandriva use Clang built kernels. LLVM is a collection of toolchain components implemented in terms of C++ objects. Clang is a front-end to LLVM that supports C and the GNU C extensions required by the kernel, and is pronounced “klang,” not “see-lang.” https://www.kernel.org/doc/html/latest/kbuild/llvm.html https://www.kernel.org/doc/html/latest/kbuild/llvm.html
kllrnohj 5y ago
GCC already has that functionality, it's called C++. Like that macro is just a crappy version of std::for_each. It doesn't seem useful to make a "C+" instead of switching to a language that just has the feature set the kernel needs. Like Rust, which is gaining some support within the Linux kernel already.
- dale_glass 5y ago
  C++ was discussed as having too many undesirable characteristics. But that's exactly why I think a customized language for the kernel is an interesting idea. You could get pretty much exactly what you want for the kernel. Add features you need, remove any undesirable behavior or features. For most programs that would be too much complexity, but the kernel has very particular needs. And I think a similar in spirit approach has worked very well with Qt.
  - Koshkin 5y ago
    The desirable characteristics of C++ overweigh, by far, its "undesirable" ones (whatever those may be, and which by the way you can for the most part safely ignore, if you wish).
    - chaxor 5y ago
      I don't know anything about C++ really, but I have been interested in learning it several times. The biggest deterrent for me has been the huge number of languages that you have to know to learn c++ it seems. Every new version comes with so many different features and seemingly (by looking for example repos on git) different paradigms that it essentially feels like many different languages. This is probably one of the biggest reasons I may turn to rust over C++ - simply less features creep due to less time being around. Can you comment on how wrong I am about my feelings this way?
      - Koshkin 5y ago
        Yes, I understand, I would probably feel the same if I wanted to learn C++ all at once and for its own sake. Luckily, I have never had to do such a thing. Indeed, I may never learn C++ in its entirety, and I may even miss some "important" pieces, but I am OK with that. I am very comfortable using C++, and I still continue picking up pieces of wisdom here and there - as I go. My advice, learn by example, start with a small project and go from there.
jancsika 5y ago
Current situation-- do nothing but yell at the compiler devs. Benefit: sometimes they listen. Cost: you cannot always (or maybe even often) get the compiler to behave as you think it should because you don't control it. Deathtrap situation-- maintain an operating system and a fork of a compiler. Benefit: you can get more control over the compiler. Cost: you still cannot always get the compiler to behave as you think due to time constraints. Death cost: your first cost is multiplied by the fact that you're now maintaining a goddamned compiler. I rankly speculate Linux is an extant project at its scale because it has refused to fight on two fronts like this. (And yelling across a border isn't the same as crossing it.) Edit: clarifications
- aliswe 5y ago
  - and you will have a compiler which is out of date.
- Too 5y ago
  On the other front they decided to write their own VCS.
stjohnswarts 5y ago
because currently gcc maintenance is almost "free" (in comparison to maintain gcc which is as big a project as linux) and they just have to work with the powers that be over at gcc. That's much better than forking it and having yet one more HUGE project to maintain independently. The advantages of sticking to the current policy FAR outweigh the disadvantages.
brenns10 5y ago
They do! Consider this patch which adds the GCC implementation necessary to make "static keys" work: https://gcc.gnu.org/legacy-ml/gcc-patches/2009-07/msg01556.html https://gcc.gnu.org/legacy-ml/gcc-patches/2009-07/msg01556.h... Static keys are a kernel API that allows code modification at runtime to achieve zero cost feature flags, like tracing: https://www.kernel.org/doc/html/latest/staging/static-keys.html https://www.kernel.org/doc/html/latest/staging/static-keys.h...
pabs3 5y ago
They do; IIRC have some GCC plugins to change various things.

deleted 5y ago

[deleted]

na85 5y ago

I'm not a compiler expert here but when clang was new and one of the BSD distros was making a lot of hay about moving to it, I remember one of the arguments in favor being that the GCC codebase is a mess and not easily extended.

Jtsummers 5y ago

That would make the code (and the compiler) non-C89 compliant. At which point, why not move to a different standard rather than bork both the kernel and the compiler if it can meet the needs better?

electroly 5y ago
The Linux kernel requires GNU extensions; it's already not ANSI C89.
- deleted 5y ago
  [deleted]
- Jtsummers 5y ago
  Alright, making it more non-compliant, then. Still creates problems for everyone and also necessitates a larger jump in the GCC version to support (unless you're going to back port the new extensions to every version that the kernel currently works with). Currently you can compile the Linux kernel with GCC 5.1. If you changed the compiler to support this one feature (or any other) you'd either need to back port it several versions (potentially back to 5) or abandon all of them. Which is probably a no-go with a project that's overall as conservative as the Linux kernel project.

initplus 5y ago

Maybe that's helpful today, but by remaining (relatively) standards compliant the kernel codebase has a more long-term resiliency. The more tightly wedded to a single compiler implementation the greater the long term risk for the project. If some shenanigans were to happen upstream in GCC it would not be the end of Linux.

colejohnson66 5y ago
But they're not standards compliant. They rely on many GCC extensions that make compiling on something else not possible.
- tinalumfoil 5y ago
  Other compilers support GCC extensions. > The Linux kernel has always traditionally been compiled with GNU toolchains such as GCC and binutils. Ongoing work has allowed for Clang and LLVM utilities to be used as viable substitutes. Distributions such as Android, ChromeOS, and OpenMandriva use Clang built kernels. LLVM is a collection of toolchain components implemented in terms of C++ objects. Clang is a front-end to LLVM that supports C and the GNU C extensions required by the kernel, and is pronounced “klang,” not “see-lang.” https://www.kernel.org/doc/html/latest/kbuild/llvm.html https://www.kernel.org/doc/html/latest/kbuild/llvm.html

kllrnohj 5y ago

GCC already has that functionality, it's called C++. Like that macro is just a crappy version of std::for_each. It doesn't seem useful to make a "C+" instead of switching to a language that just has the feature set the kernel needs. Like Rust, which is gaining some support within the Linux kernel already.

dale_glass 5y ago
C++ was discussed as having too many undesirable characteristics. But that's exactly why I think a customized language for the kernel is an interesting idea. You could get pretty much exactly what you want for the kernel. Add features you need, remove any undesirable behavior or features. For most programs that would be too much complexity, but the kernel has very particular needs. And I think a similar in spirit approach has worked very well with Qt.
- Koshkin 5y ago
  The desirable characteristics of C++ overweigh, by far, its "undesirable" ones (whatever those may be, and which by the way you can for the most part safely ignore, if you wish).
  - chaxor 5y ago
    I don't know anything about C++ really, but I have been interested in learning it several times. The biggest deterrent for me has been the huge number of languages that you have to know to learn c++ it seems. Every new version comes with so many different features and seemingly (by looking for example repos on git) different paradigms that it essentially feels like many different languages. This is probably one of the biggest reasons I may turn to rust over C++ - simply less features creep due to less time being around. Can you comment on how wrong I am about my feelings this way?
    - Koshkin 5y ago
      Yes, I understand, I would probably feel the same if I wanted to learn C++ all at once and for its own sake. Luckily, I have never had to do such a thing. Indeed, I may never learn C++ in its entirety, and I may even miss some "important" pieces, but I am OK with that. I am very comfortable using C++, and I still continue picking up pieces of wisdom here and there - as I go. My advice, learn by example, start with a small project and go from there.

jancsika 5y ago

Current situation-- do nothing but yell at the compiler devs. Benefit: sometimes they listen. Cost: you cannot always (or maybe even often) get the compiler to behave as you think it should because you don't control it. Deathtrap situation-- maintain an operating system and a fork of a compiler. Benefit: you can get more control over the compiler. Cost: you still cannot always get the compiler to behave as you think due to time constraints. Death cost: your first cost is multiplied by the fact that you're now maintaining a goddamned compiler. I rankly speculate Linux is an extant project at its scale because it has refused to fight on two fronts like this. (And yelling across a border isn't the same as crossing it.) Edit: clarifications

aliswe 5y ago
- and you will have a compiler which is out of date.
Too 5y ago
On the other front they decided to write their own VCS.

stjohnswarts 5y ago

because currently gcc maintenance is almost "free" (in comparison to maintain gcc which is as big a project as linux) and they just have to work with the powers that be over at gcc. That's much better than forking it and having yet one more HUGE project to maintain independently. The advantages of sticking to the current policy FAR outweigh the disadvantages.

brenns10 5y ago

They do! Consider this patch which adds the GCC implementation necessary to make "static keys" work: https://gcc.gnu.org/legacy-ml/gcc-patches/2009-07/msg01556.html https://gcc.gnu.org/legacy-ml/gcc-patches/2009-07/msg01556.h... Static keys are a kernel API that allows code modification at runtime to achieve zero cost feature flags, like tracing: https://www.kernel.org/doc/html/latest/staging/static-keys.html https://www.kernel.org/doc/html/latest/staging/static-keys.h...

pabs3 5y ago

They do; IIRC have some GCC plugins to change various things.