Shared publicly  - 
To clarify a few things regarding that "debug" mess:

I will change systemd to not log to kmsg if journald is around when "debug" is specified. We will continue to log to kmsg during the early bootphase however als long as journald is not running yet. At that point there is simply no other option for that, because persistent storage is not available yet at that point and we need som way for people to get their logs out of the system, and early kmsg is the only way really, since it is hooked up with netconsole, serial tty, crashkernels, ... and all that other stuff.

I also believe that it is the right thing for the kernel to ratelimit whatever userspace sends it. For the same reason as we have to ratelimit all log streams in journald too, regardless where they come from. If you get a stream of logs from a 'differently priviliged' component then you need to rate limit it, that should be common sense. Of course I wish the ratelimiting applied is always configurable for the user, so that he can control how much and how soon things get dropped.

For me it is out of question though that systemd and other core os components should continue to parse the 'debug' kernel cmdline option, and increase their debug levels then. Generic options like that are supposed to be useful for real people, and there's a long history of options like that which influence both kernel and userspace (quiet, root=, ...). We are putting together an OS here after all, not just a kernel, and a kernel is just one component of the OS among many, and ultimately an implementation detail. We are writing an OS here for the general purpose, not just a toy for a clique of kernel developers. Moreover, there are individual kernel cmdline options for both the kernel itself and systemd to control just their log levels, and nothing else. so if you want finegrained control, you already have it, 'debug' is just the simple option that groups them all under a single oneshot option. It's the option an admin can specify which tells him why the system doesnt boot, regardless whether the kernel or systemd is at fault or any other part of the core os involved in boot. Thats simply userfriendly.

I do not appreciate all that talk from certain parts of the community that the systemd folks need to 'get tought a lesson'. That turns this into some kind of power game, which I am totally not interested in. Comparing us to Putin, or trying to bind merging of completely unrelated code to us doing whatever some kernel devs want (which is blackmail at worst, and childish at best, and childish we can be on our own enough, thanks) will just make us ignore you, and that's it. I prefer to deal with technical questions, and intimidation is not a technical question.

what the various news outlets wrote about all this is quite ridiculous. It's sad how badly these sites report, quite a shame.

And that is all.
Tomáš Pružina's profile photoGreg Kroah-Hartman's profile photoDavid Page's profile photoThomas Eichberger's profile photo
+Kay Sievers look for +Linus Torvalds comments on lkml...
He is NOT very pleased. And he says it will not take any patch from you until you reconsider. And that is an history of annoying bugs.
my last kernel patch is more than a year old, my last non-trivial kernel patch 2 years old. i stopped working on the upstream kernel "long ago" for reasons i cannot stand the attitude of these guys, i decided to work with grown up or funny, or grown up and funny people instead and i enjoy it a lot more. not sure what this childish blackmail attempt relates to.
Why not just use "systemd.debug" so the "debug" keyword doesn't collide?
+Kyle Manna then you will have to ask the same to all other projects that use "debug" in the boot command line.. including but not limited a bunch of installers, some bits of the old init tools etc.. but no, it is more convenient to single out systemd the favorite scapegoat. 
+Kay Sievers "not sure what this childish blackmail attempt relates to" -  I'm going to go out on a limb and say that it relates to the quality of your code

perhaps if you wrote better quality code, he wouldn't be publically bashing you about it....
+Chris Thomas No, it has to do with Torvalds being the same obnoxious  prick he has always been. who feels entitled to command people to comply with his wishes, somebody has to stop him someday. 
you know the source code is free so go play with it Cristian.  That simple. I do not give one sh_t about Linus. That's his sand box you want to play in it  then play in it. The gnu is one thing the kernel is another sandbox. Take the code and go make sand.
And If Linus Talks like a 15 year old so be it. He think he is being direct. He is to the point.

I don't need sugar to play in his sand box.
PREFACE: I like systemd ideas and I think sysvinit did its time and it needs a replacement.

However, +Kay Sievers, you say you can't stand with the kernel guys' attitude - but how is their attitude different than closing a bug report[1] without a resolution and saying "not my problem"?

It's not my interest in feeding the flames, I'd just like to point out that maybe everyone should display a bit more humility in recognizing issues and fixing them, for the greater good of the OSS ecosystem.

I see a battle going between veterans and young rockstars and I think it can bring us to either a deep crash or to beautiful progress. Shall we all strive for the latter? :-)

Thanks for reading.

+Marcello Barnaba There is no battle between young and old, see , a large number (but not all. mind you) kernel developers are insufferable sneaky, condescending, demanding, arrogant pricks, and this is noting new, has been going on for decades. to understand what I am talking about, read LKML. try interacting with them once in a while and see for yourself.
+Cristian Rodriguez I've read LKML in the past, I know +Linus Torvalds' way of leading; and I'm not impressed if other developers act similarly. Because, I think, if we work in Open Source, we are passionate about what we do, and from great passion come both big hugs and big swears :-).

What I see been going on for decades is a successful OS kernel project with thousands of loosely-knit contributors from all over the planet. It's an unmatched, impressive result. It works.

I would mind about this result, instead of the amount of fucks and shits and name-calling - as the bugs over which we argue couldn't care less about our arguing - they just need to be squashed away, and that is the whole point, IMHO.
Hm, linux needs to ratelimit it because there is very real risk of pissing into circular buffer of relatively small size, systemd needs to ratelimit stuff because by default log size can go up to 10% of hdd (as far I know), which on modern systems can mean 200 GB.

200 GB > 64KB of ram in circular buffer (they don't make hashes of their circular logs either).
Add a comment...