Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

From: Linus Torvalds
Date: Wed Apr 02 2014 - 19:13:40 EST

On Wed, Apr 2, 2014 at 3:12 PM, Mateusz Guzik <mguzik@xxxxxxxxxx> wrote:
> Well, parsing kernel cmdline by systemd is a bad idea

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. The kernel doesn't complain about flags it
doesn't recognize, exactly because the kernel realizes that "hey,
maybe this flag is for something else".

The classic example of this is things like "charset" markers, but also
options to modules that modprobe parses etc etc.

And yes, that does include "quiet" and "debug". Parsing them and doing
something sane with them is not a bug, it's a feature.

But the problem appears when system services seem to think that they
*own* those flags, and nothing else matters, and they don't do
something "sane" any more.

And the thing is, this has never really been a problem in practice.
Because nobody minds if some kernel option like "debug" makes not only
the kernel enable debugging, but some system deamon log a bit more


It does become a problem when you have a system service developer who
thinks the universe revolves around him, and nobody else matters, and
people sending him bug-reports are annoyances that should be ignored
rather than acknowledged and fixed. At that point, it's a problem.

It looks like Greg has stepped in as a baby-sitter for Kay, and things
are going to be fixed. And I'd really like to avoid adding hacky code
to the kernel because of Kay's continued bad behavior, so I hope this
works. But it's really sad that things like this get elevated to this
kind of situation, and I personally find it annoying that it's always
the same f*cking primadonna involved.

Steven, Borislav, one thing that strikes me might be a good idea is to
limit the amount of non-kernel noise in dmesg. We already have the
concept of rate-limiting various spammy internal kernel messages for
when device drivers misbehave etc. Maybe we can just add rate-limiting
to the interfaces that add messages to the kernel buffers, and work
around this problem that way instead while waiting for Gregs fix to
percolate? Or are the systemd debug messages going to so many other
places too that that wouldn't really help?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at