> That says nothing about why the systemd folks are entitled to hijacking a kernel flag instead of (more sanely) namespacing their own debug flag
"No, 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."
> which is the actual bug that was filed (and in turn met with "it's not a bug it's a feature,
And that is the appropriate response to the bug that was filed, with the title "Do not parse "debug" command line parameter".
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!
Kay pointed out in his first comment that there is already a different parameter that turns on debug output only for the kernel; the reporter said he's too lazy to start using it.
And this is not about "entitlement": there is a clear administrative use-case for systemd using the debug parameter: if your system doesn't boot you want a simple and obvious way to turn on debug logging in all of the relevant plumbing code, whether it's in the kernel, in the initrd or during service startup. You shouldn't have to remember five different parameters because then you'll forget one and your outage lasts 10 minutes longer.
If the bug report had been something more like "I've enabled debug and my system failed to boot" without prescribing a particular fix and leaving that at the maintainer's discretion, it wouldn't have been resolved as NOTABUG but fixed quickly.
Of course, a wiser and more socially skilled maintainer than Kay Sievers would have immediately filed a follow-up bug report, or re-titled the bug report instead of lowering himself to the level of the reporter and playing resolve-reopen ping pong. (Fortunately the systemd project also also has some more patient maintainers like Tom and Zbigniew.)
Read the rest of the email you linked, where Linus clarifies that systemd's use of the 'debug' parameter seemed to assume that systemd was the only user of it, thus going against the whole point of a readable /proc/cmdline. Thus, feedback loops were caused and pain was created and flamewars were started.
Again, if you shove your hand into a fire, don't blame the hand (or, for that matter, the fire) for your own arrogance and stupidity. Common bloody sense.
If you discount the usual Linus style hyperbole from the rest of that mail, the only thing that remains is that Linus is unhappy with the fact that Kay closed that bug report instead of trying to find the root cause of the reporter's boot failure.
"No, 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."
http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01488.html
> which is the actual bug that was filed (and in turn met with "it's not a bug it's a feature,
And that is the appropriate response to the bug that was filed, with the title "Do not parse "debug" command line parameter".
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!
Kay pointed out in his first comment that there is already a different parameter that turns on debug output only for the kernel; the reporter said he's too lazy to start using it.
And this is not about "entitlement": there is a clear administrative use-case for systemd using the debug parameter: if your system doesn't boot you want a simple and obvious way to turn on debug logging in all of the relevant plumbing code, whether it's in the kernel, in the initrd or during service startup. You shouldn't have to remember five different parameters because then you'll forget one and your outage lasts 10 minutes longer.
If the bug report had been something more like "I've enabled debug and my system failed to boot" without prescribing a particular fix and leaving that at the maintainer's discretion, it wouldn't have been resolved as NOTABUG but fixed quickly.
Of course, a wiser and more socially skilled maintainer than Kay Sievers would have immediately filed a follow-up bug report, or re-titled the bug report instead of lowering himself to the level of the reporter and playing resolve-reopen ping pong. (Fortunately the systemd project also also has some more patient maintainers like Tom and Zbigniew.)