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.

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

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.

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...

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)

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

You explanation was specific and helpful. Thanks

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.