Linus Torvalds suspends key Linux developer

[Recursion]

http://www.networkworld.com/news/2014/040314-linux-280404.html

An argument between developers of some of the most basic parts of Linux turned heated this week, resulting in a prominent Red Hat employee and code contributor being banned from working on the Linux kernel.

Kay Sievers, a well-known open-source software engineer, is a key developer of systemd, a system management framework for Linux-based operating systems. Systemd is currently used by several prominent Linux distributions, including two of the most prominent enterprise distros, Red Hat and SUSE. It was recently announced that Ubuntu would adopt systemd in future versions as well.

Sievers was banned by kernel maintainer Linus Torvalds on Wednesday for failing to address an issue that caused systemd to interact with the Linux kernel in negative ways. Specifically, the command line entry “debug” ran both the base kernel’s debugging routine and that of systemd, potentially flooding some systems.

Torvalds bashed Sievers for lacking responsibility in a mailing list message. “Key [sic], I'm [expletive] tired of the fact that you don't fix problems in the code you write, so that the kernel then has to work around the problems you cause,” he wrote.

This is kind of a shame in that Linus's profanity-laced rants against Sievers and Poettering are one of the things that makes the Kernel mailing list interesting to read...

[bananas]

1. wtf

http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01327.html

It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool parses the
kernel command line, and if it sees "debug" it will spit out so much
information that the system fails to boot. This basically renders the
"debug" option for the kernel useless.

[defacto7]

2. Although I see Andrea's point in principle

I don't see the necessity of having "debug" visible in /proc/cmdline just to save some debug time. Seems more important to keep wandering init proc at bay for stability. So I guess this means I'm not quite up to their level and probably don't get the point.

I vote Linus.

[Recursion]

4. The real problem is there should not be a "wandering init proc"

Take OpenBSD or Slackware's init: beyond some compiler macros and other conveniences, it boils down to this:

#include <signal.h>
#include <unistd.h>

int main()
{
sigset_t set;
int status;

if (getpid() != 1) return 1;

sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, 0);

if (fork()) for ( ; ; ) wait(&status);

sigprocmask(SIG_UNBLOCK, &set, 0);

setsid();
setpgid(0, 0);
return execve("/etc/rc", (char **){ "rc", 0 }, (char **){ 0 });
}

PID 1 shouldn't be doing anything else. I mean, seriously, did anybody look at their init program and think, "man, what this really needs is a log colorizer and QR code validator..."

[defacto7]

6. "PID 1 shouldn't be doing anything else"

I suppose not. I was reading Andea's input and it seemed like she was thinking a little out of box and I like that, but that doesn't mean a ringer of a code advancement. But it's not being taken very well but other developers. I'm learning a bit.

[Recursion]

8. Oh, now I see what you're talking about. Andrea's thing is a different thread

The web interface isn't exactly intuitive, I'm afraid; "previous message" is simply in temporal order, not in thread order. LKML can be really interesting to read, though...

[Recursion]

3. There was an assertion failure in systemd

In principle there's no reason an init shouldn't look at the kernel command line and be more verbose if debug is specified; the problem here was that systemd had two failed assertions that spammed kmsg.

The context here is that udev has been more or less broken since Sievers took it over a few years ago, and Linus has grown progressively more frustrated with

1. its firmware loading not checking for race conditions that lead to a lockup, and
2. Siever's insistence that loading firmware shouldn't be udev's job and the kernel should do it (putting the loading of firmware into userspace was the specific purpose for leaving devfs for udev in the first place)

[defacto7]

5. On what kernels are these problems centering now?

Just in early development stages or are they out in the dev repositories for our own perusing?

You explanation was specific and helpful. Thanks

[Recursion]

7. That will hit any kernel whatsoever; it's a bug in systemd

There are invalid assert() calls in systemd that fill up kmsg (because PID 1 has to write to kmsg before the regular dmesg ring is brought up) to such an extent that getty or logind or whatever can't spawn a new login shell.

On the plus side, Sievers is the one responsible for the wrongheaded and potentially disastrous push to move all of dbus into the kernel, so this delays that for a while, thankfully.