Systemd catches up with bind events

Posted Nov 14, 2020 0:39 UTC (Sat) by foom (subscriber, #14868)
In reply to: Systemd catches up with bind events by willy
Parent article: Systemd catches up with bind events

"You can't use the boot command line option 'debug', it's ALL MINE!"...Seriously? "Coopting"?

As a user, I'm sure I don't really care which part of the system boot is implemented by code in the kernel and which is implemented in systemd/udev/etc. I just want them to work together to boot the system properly. I mean, it makes sense to me that if I want to debug an issue, that everyone would respond to the one debug flag...

And same for "This incompatibility is all their fault!" -- again...who cares? It's nonsense.

Systemd catches up with bind events

Posted Nov 14, 2020 13:30 UTC (Sat) by willy (subscriber, #9762) [Link] (1 responses)

Uh, yes, "coopting".

"divert to or use in a role different from the usual or original one"

What word would you use to describe using something for your own purposes that somebody else was already using? It's not like I said "stealing".

Systemd catches up with bind events

Posted Nov 14, 2020 16:26 UTC (Sat) by pbonzini (subscriber, #60935) [Link]

When you say "the original purpose" of /proc/cmdline and the debug flag, do you mean "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"."?