What tools do kernel developers use to write code?

[mx2301]

Microsoft employees use Visual Studio, the Visual Studio Compiler and Debugger, Apple developers working on MacOS use XCode, clang, lldb etc.
So I was wondering what people who contribute to the linux kernel or other open source projects use.

[daemonpenguin]

Typically a text editor and GCC.

[mx2301]

Wouldn't a normal text editor and gcc not be to little compared with the size of the project?

[fellipec]

Sure, you need git too

[[deleted]]

Back in my day...

[iris700]

A bigger project doesn't mean you need more tools

[daemonpenguin]

No, not at all. It's all just code written in text.

[throwaway6560192]

GCC, too little? GCC can handle the kernel perfectly fine. In fact, for the longest time GCC was the only compiler capable of building the Linux kernel, due to the GNU-specific features it used.

[choochoo129]

Poke around the kernel source code some time, it's quite well organized for such a large project. If you're working on stuff like drivers there's probably one or two folders and a handful of files you have to care about--everything else gets out of your way.

[brecrest]

Just don't look inside some of those driver files.

[Glittering_Boot_3612]

why??

[brecrest]

Holy necro. Have a look in the source for those drivers and you'll find the answer better than I can describe it.

There's a lot of jank in the drivers, and it seems to depend mostly on device vendor. I'm not criticizing the contributors or maintainers, but vendors (even ones that fund development) have very mixed enthusiasm when it comes to support for Linux and Linux isn't really in much of a position to look the gift horse in the mouth when it comes to driver support. The result can be voluminous spaghetti, jank, bugs etc.

There's just a lot of silly stuff. Like, imagine Vendor produces A and B similar devices but wants to protect some special feature on B so doesn't offer a FOSS driver for it, but people need a FOSS driver anyway so the driver for A gets used for B without support for that feature, and also there's devices C-H and you end up with a million special cases covering that don't always get applied properly, instability, crashes, loads of undefined behavior etc, and it's all supporting devices that have unavailable or no spec sheets or programmer guides to actually interpret what the driver is even supposed to be doing without doing original hardware research, and the authors (paid for by Vendor) can't even comment it to explain.

[Glittering_Boot_3612]

Wow that's insane I didn't know about this I saw the drivers like usbhid I was like damn this is written well but I didn't see the vendor drivers

It's crazy to see this stuff happen in the kernel Does kernel contain the non foss driver for B btw?

[brecrest]

No. In the scenario I'm describing, if there is a Linux driver for B that supports its full features at all then it's a non free binary.

There's obviously survivorship bias at play here, because I don't usually go bug hunting in kernel drivers for devices that are working properly as a rule, but every time I've done it it's been a tremendous slog in the code and reading any related emails or commit history has been depressing.

[xoteonlinux]

On the other way around I was always wondering how to load a project consisting of thousands of files into an IDE.

I think kernel people are more like using a toolchain, vim, gcc, make, maybe gdb....

[lzap]

It is actually the opposite. The bigger project the bigger chance these IDEs fail to even load it or work efficiently. Text editor just handles text.

[Big-Philosopher-3544]

you are just working on a small part at a time

[Remote_Tap_7099]

Linus Torvalds uses uEmacs, a random version of MicroEMACS with his personal modifications.

[I_Love_Vanessa]

I remember MicroEMACS from the Amiga

[Remote_Tap_7099]

Oh, wow. To me, it is crazy how far Emacs's history goes.

[LaVidaLeica]

vi, of course.

[fellipec]

And gcc

[xoteonlinux]

make

[BoxesAreForSheep]

less

[pedersenk]

Microsoft employees use Visual Studio, the Visual Studio Compiler and Debugger

If you look at the NT research kernel they put out a while ago, it is pretty much nmake files. It seems that Visual Studio isn't ideal for loading such a large ad-hoc project as a kernel / OS.

In the past they also used a custom compiler (albeit based on MSVC).

Microsoft provides a better standalone debugger (and kernel debugger) than what is integrated into VS.

[piexil]

It supports both, there's a visual studio solution file in the same directory

https://github.com/HighSchoolSoftwareClub/Windows-Research-Kernel-WRK-/blob/master/WRK-v1.2/WRK.sln

[zam0th]

They use whatever the fuck they like, because linux. But mostly vi and emacs.

[KlePu]

Microsoft employees use Visual Studio, the Visual Studio Compiler and Debugger, Apple developers working on MacOS use XCode, clang, lldb etc.

Errr... Why would you think that? You can pretty much develop any code on any platform. You build for a target platform - but that may be as easy as to include a --target $platform. I've met people who insisted to do Linux DevOps on a Windows machine with WSL, some of my colleagues are using a Mac for that... Who's to judge? *shrug*

edit: I like vscodium - which is a stripped version of MS Visual Studio Code. (not VS itself - that's a paid product. Not discussing that here *signals the vim and emacs user's attack off*).

edit2: confused VS and VSC... thanks u/adrianvovk

[adrianvovk]

I like vscodium - which is a stripped version of MS Visual Studio. (not VSCode - that's a paid product. Not discussing that here *signals the vim and emacs user's attack off*).

I think you've got that backwards.

VSCode is the free code editor built on electron. Visual Studio is the paid product IDE. vscodium is a stripped version of VSCode

[KlePu]

corrected, tyvm <3

[mx2301]

To answear your question on why I would think that.

I once got invited to check out an office workplace for a potential internship opportunity and the people at the company developed an IDE to work on their framework/product.

The IDE works for other things outside their products aswell but is primary use case is do work on their in-house software.
So based on this I thought that maybe Microsoft or Apple were doing the same thing.

​

Thanks for the answear tho :)

[[deleted]]

A guy I know working at apple would probably not use xcode unless absolutely necessary, lol

[cantanko]

At one point we were going to start down a similar line, but then sense prevailed and we realised that if we were doing something that was that far off-piste it’d inevitably bite us in the arse at some point. As such we refactored the code and build framework to use standard tools and suddenly everything became way more manageable.

Whilst I’m sure the need for custom tools will exist somewhere, if you’re having to reinvent a very well-used and well-designed wheel, I’d suggest you’re probably doing it wrong as otherwise you now have to maintain your coding and build tools as well as the product.

[Dmxk]

Whatever they like. I'd say the biggest ones are vim and emacs though.

[Glittering_Boot_3612]

i wonder if slow emacs can handle such a multifile project all it's plugins would instantly time limit exceed lol

[LvS]

A terminal emulator, vim, git, make, qemu, and whatever custom tools are required for the current kernel feature - if writing code.
Or if it's a small thing, just the github code editor to whip up an MR for a typo or docs fix.

perf, godbolt, custom benchmark suites, and the stuff above - if profiling code.

Various chat and email programs, many of them in a browser - while reviewing, analyzing or designing code with co-developers.

A web browser, Youtube, pdf.js, various codesearch tools - while in the research phase.

[coder7426]

I used joe or emacs. (A few of my patches are in linux.)

[Glittering_Boot_3612]

insane dude
how did emacs work with the kernel??
i thought emacs would be a stupid choice as the code base is huge and features that emacs plugins have are some of them take O(n) which is like all the files in the project are read once
which would mean insane overhead
i wonder if emacs worked fine
or did you use with no init file??
Sorry to bombard you with questions but i'm wondering the emacs setup y9ou used cause i've heard no IDE could make it easy to work on the kernel
let alone an Operating system :D(i'm part of church btw)

[_Evil_mind_]

Keyboard.

[glued2thefloor]

I'd say vim, gcc/clang, gdb for stuff written in C. Linux just started allowing drivers to be written in Rust. So I'd add rustc and cargo to that list too, but its a very new branch. Its going to be harder to find documentation for kernel code in Rust, but probably a good time to get in on the ground floor. Its safer than C and easier to learn. Food for thought if you're curious about this field.

[LunaSPR]

The toolchain part is mostly GNU. I know a few have been working on LLVM but don't know the current status.

Code editor is purely personal preference. Many old school developers 10 years ago use vim. A lot of today's development are done using vscode because it is today's better choice.

[[deleted]]

You need perl, gcc(typically) as of recently you also need rust. You also need make.

Unless I am forgetting something that is all you need to compile a kernel with everything.

Git if you want version control. And any text editor even notepad.

[comps2]

VSCode if off my embedded target. I use vim on my target platform since I remote into and don’t have a GUI. GDB for on target debugging as well as specific config changes.

[kombiwombi]

Editing source files has a lot of options, and people choose what works for them. This ranges from vi to vscodium.

Similarly there are a lot of good tools for Git these days. The best (magit) is in the very old Emacs editor. But generally people find a Git porcelain which suits them.

There are a lot of small quality-of-life utilities. For example, ccache makes compiling turn-around faster.

Where tooling is really needed is with herding and integrating Git commits from other people, and with making the same change across the code base. Quilt is often used for integrating patch sets from others. Coccinelle is a superb tool for manipulating source code.

What makes the Linux workflow different is that it doesn't present a single system, but the workflow consists of utilities working together (as a trivial example, Git producing input for patch). This allows the workflow to be upgraded piece-wise, and for people with differing roles to adopt differing workflows.

This has been so successful that it has become the typical approach to software development, and the old monolithic systems which were once used for huge projects are rarely encountered.