Just like "quiet", which is totally meant to affect userspace programs.
> It's a ridiculous clunky hack that stinks of large company coding practice: what they actually needed was a way to pass arguments to systemd itself.
Having a global "debug" knob would have been useful when one does not know if the problme lies in the ramdisk, plymouth, systemd, udev, lvm, whatever. Having a systemd-specific flag defeats that purpose.
> The logical way to do that in an OS that has to be portable and flexible is to implement a mechanism for the kernel to pass some of the arguments it receives to init. Because there's no reason to assume that init is going to be systemd, that there's going to be a procfs ready for it so as to be able to read the kernel's parameters, or that the init process can read it for that matter.
The kernel command line, readable from procfs, has been used for this purpose (see the "quiet" flag) for a very long time now.
> what do you mean "this can have unwanted side-effects", it works perfectly fine on my system.
It worked perfectly on every system until the kernel bug triggered the feedback loop.
> The fact that the developers (again, it's a known pattern) decided to play the PR game and call it "expected behaviour" doesn't make it less of a bug.
It was "expected behaviour" in the presence of a kernel bug, which is why it was obviously not generally "expected behaviour" as you seem to imply.
> What userspace programs interpret the quiet parameter?
> Genuine question. AFAIK, quiet does (or should do) nothing other than disable some of the kernel logging.
At least plymouth and probably every init system out there.
Linus said that "we very much expose /proc/cmdline for a reason. System services
are supposed to parse it, because it gives a unified way for people
to pass in various flags. [...] And yes, that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature."
> The bug report makes it immediately clear that this is not really about a technical problem that ought to be solved - no, the dirty user-space programmers should get their stinking paws off of our good kernel command line flags, how dare they!
You're right that Kay was wrong to close the bug immediately instead of trying to help finding the real cause, and you're wrong when you say that userspace should not parse the kernel command line, see Linus' remark above.
> There's no reason to even assume procfs will always be there
To the contrary, dropping it would be an ABI break so it's really safe to assume that it will be always be there.
> who's been programming for more than an year
Please, don't lecture others about their job. I'm not assuming you're an incompetent fool, please don't assume I am.
> if a program did that on Windows
And can we try to stay relatively on topic? Windows is definitely unrelated.
(I'm not otherwise replying in detail because you assumed that parsing the kernel command line was not ok, while Linus officially blessed its usage. Also we reached the max thread depth on HN, which should probably suggest something.)
> Just like "quiet", which is totally meant to affect userspace programs.
What userspace programs interpret the quiet parameter?
Genuine question. AFAIK, quiet does (or should do) nothing other than disable some of the kernel logging.
> Having a global "debug" knob would have been useful when one does not know if the problme lies in the ramdisk, plymouth, systemd, udev, lvm, whatever. Having a systemd-specific flag defeats that purpose.
Yes, and it would have been very useful if the systemd team had offered to implement such a feature, instead of silently pretending to have it.
That thing was news to everyone. Except Kay Sievers, apparently, who chose to share the big news with the world when closing the bug report.
> The kernel command line, readable from procfs, has been used for this purpose (see the "quiet" flag) for a very long time now.
By what non-broken programs? There's no reason to even assume procfs will always be there, let alone that the kernel will expose its boot parameters through it. AFAIK, quiet doesn't affect anything but the kernel's logging.
With obvious exceptions (e.g kernel debugging tools and the like), that shouldn't happen.
> It worked perfectly on every system until the kernel bug triggered the feedback loop.
No no. It worked perfectly because the systemd team never bothered to see what happens when the kernel actually tries to use the debug flag, too (i.e. when an assertion actually fires). It should be obvious to anyone who's been programming for more than an year or so that, when you start parsing arguments that aren't yours (which is bad enough in the first place!) you should at least ensure that you don't break the program that uses it.
Yes, the rate limit for /dev/kmsg was increased when it turned out there was a potential to incapacitate the system by flooding the kernel with data from userspace. For what it's worth, if a program did that on Windows, every half-assed heuristic detection engine would have promptly flagged it as malware.
> It was "expected behaviour" in the presence of a kernel bug, which is why it was obviously not generally "expected behaviour" as you seem to imply.
How the hell is "I'm passing an argument to the kernel and a program from userspace decides to interpret it" expected behaviour? If I pass rw, too, should I now expect mount to mount every system as read-write?
Just like "quiet", which is totally meant to affect userspace programs.
> It's a ridiculous clunky hack that stinks of large company coding practice: what they actually needed was a way to pass arguments to systemd itself.
Having a global "debug" knob would have been useful when one does not know if the problme lies in the ramdisk, plymouth, systemd, udev, lvm, whatever. Having a systemd-specific flag defeats that purpose.
> The logical way to do that in an OS that has to be portable and flexible is to implement a mechanism for the kernel to pass some of the arguments it receives to init. Because there's no reason to assume that init is going to be systemd, that there's going to be a procfs ready for it so as to be able to read the kernel's parameters, or that the init process can read it for that matter.
The kernel command line, readable from procfs, has been used for this purpose (see the "quiet" flag) for a very long time now.
> what do you mean "this can have unwanted side-effects", it works perfectly fine on my system.
It worked perfectly on every system until the kernel bug triggered the feedback loop.
> The fact that the developers (again, it's a known pattern) decided to play the PR game and call it "expected behaviour" doesn't make it less of a bug.
It was "expected behaviour" in the presence of a kernel bug, which is why it was obviously not generally "expected behaviour" as you seem to imply.