Talk:Linux kernel

How a Linux kernel developer sees the free+open source vs. proprietary debate

I'm a Linux developer since April 2021. While still a newcomer I've been working literally across all its subsystems. I've been one of the most prolific contributor for the v5.19. At LWN I am ranked 12th of 2086 contributors per lines of code: https://lwn.net/Articles/902854/

"Linux" from now on explicitly refers to the kernel of several operating systems. This discussion has nothing to do with an unrelated debate about the most suited names those OS.

Let's go on to the core of my intervention...

Everybody knows that the official Linux is released by Mr. Linux Torvalds. His repository can be easily reached at kernel.org. Users can use "git-clone" to download git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ in their working space. Users can read, change, and submit their signed patches to the kernel to the relevant maintainers and lists. Good practice wants to always also Cc the LKML.

The fundamental information many are still missing is that the code of Linux is only a subset of what people clone from Torvalds tree.

This is not a minor detail. Linux is only a subset of whatever is hosted in Torvalds tree. ./torvalds/linux.git contains much more than Linux. For example, it contains several user space tools, tests, scripts for helping with development, static analyzers, documentation, firmware, code examples, and many other things.

To summarize: ./git/torvalds/linux.git != Linux. ("!=" is a C operator which means "not equal").

Whoever affirms that ./git/torvalds/linux.git == Linux is ill informed, at best.

Linux is free and open source and furthermore it provides a very complex but exhaustive means to enable / disable thousands of features before users build the executable kernel object, according to their particular needs and preferences and also to explicitly avoid the inclusion of non proprietary binaries into the kernel image.

Whoever distributes binary kernel images must disable the inclusion of non free and open source code, otherwise they infringe the laws. The international laws don't allow the distribution of proprietary code in the same executable built with GPL-v2-only code. It would be a serious infringement and I'm not aware of any major distributions which is willing to take that legal risk.

However, the kbuild infrastructure has several options which developers and users (those who won't redistribute their customized kernel images) may enable or disable to change how the kernel handles firmware (regardless it being a binary blob or free and open source).

Before going on, don't forget that, from a logical point of view, a "firmware" is a different class of software with respect to a "kernel", it serves other purposes and it is not a subsystem of any kernel, including proprietary kernels. The kernel merely sends the firmware to the devices controllers that need and run them.

They don't share the same address space and can't request services each others if not via standard API in the relevant device drivers. Therefore, if device drivers are open source we know that they can't manipulate or leak user and kernel data. No device drivers in Linux are proprietary. We have the code and we can check what they send to the device controllers or viceversa.

For due completeness...

Linux provides an option to build firmware blobs into the kernel or forbid that build. The option is called CONFIG_EXTRA_FIRMWARE and if users need a .bin file into the kernel image they must explicitly name that binary before building the kernel.

The following paragraphs are copy-pasted from the online help of the Kbuild infrastructure which is responsible of kernel configuration:

"[] For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy the usb8388.bin file into /lib/firmware, and build the kernel. Then any request_firmware("usb8388.bin") will be satisfied internally inside the kernel without ever looking at your filesystem at runtime. WARNING: If you include additional firmware files into your binary kernel image that are not available under the terms of the GPL, then it may be a violation of the GPL to distribute the resulting image since it combines both GPL and non-GPL work. You should consult a lawyer of your own before distributing such an image.".

Users who don't need firmware built into the kernel may instead enable the CONFIG_FW_LOADER which loads firmware at runtime from specific user space directories, or they may also rely on CONFIG_FW_UPLOAD which, when enabled, allows device drivers, which instead are indeed a logical part of a kernel, to expose a persistent sysfs interface that allows firmware updates to be initiated from power users at will. Fabio Maria De Francesco (talk) 05:30, 20 September 2022 (UTC)

@Fabio Maria De Francesco I didn't see a point. In truth, I didn't read it all since it's so rambling. Can you summarize your thoughts in one sentence? What do you want to add, remove or change in the article? Stevebroshar (talk) 20:39, 16 May 2024 (UTC)

Rust language

Rust is mentioned in the infobox, but nowhere in the article text, specifically § Programming language and coding style. This probably should be addressed. ☆ Bri (talk) 16:33, 27 February 2023 (UTC)

It's mentioned under Programming language at this point. So, I guess your concerned is addressed. Stevebroshar (talk) 20:35, 16 May 2024 (UTC)

Modular is the opposite of monolithic

Since modular is the opposite of monolithic, readers with both words in their vocabulary (like me) will notice the contradiction. Thing is, the article is not wrong. Linux kernel is a monolithic kernel which has a specific meaning ... which is unrelated the modularity of the system in the sense it is modular.

Interestingly, our AI overlord says this: The first version of the Linux kernel was monolithic, not modular. A monolithic kernel is a single executable that includes all the code required, including device drivers. A modular kernel, on the other hand, has a core kernel with only the necessary code, along with modules of code that may be needed as separate entities. Modular kernels have been available since version 1.1.85 in January 1995, when Red Hat Linux 3.9 introduced modules instead of monolithic kernels.

So, Linux today is a modular kernel but it used to be monolithic. But it's also monolithic. :)

Describing that in the first sentence is foolhardy. So, that info should be later in the article.

Also, IMO, that Linux is monolithic/modular and monolithic is not the most interesting aspects of Linux kernel and therefore should not be mentioned in the first sentence for that reason. What's interesting about Linux kernel is that it has the capabilities of UNIX, but unlike any previous UNIX like kernels, it was and is free, _and_ that it is so insanely popular it's in a zillion computers today. In a later section, we can tell the nerds (like me) that it's both modular and monolithic. Stevebroshar (talk) 00:23, 22 May 2024 (UTC)

EEDVF/CFS

The article talks about CFS as if it's the current scheduler still, and only mentions EEVDF briefly at the end of the section. The section should be rewritten to discuss EEVDF first, with CFS discussed as the previous scheduler. Alex Martin (talk) 13:23, 20 July 2024 (UTC)