3 ms·

> Or even that Linus Torvalds (who's often complained about how bugs in systemd get pushed back as bugs in the Linux kernel) doesn't know his stuff either? Whe

> Or even that Linus Torvalds (who's often complained about how bugs in systemd get pushed back as bugs in the Linux kernel) doesn't know his stuff either? When did that happen? There was one udev bug regarding firmware loading where during the discussion it turned out that it's the right thing to do that in the Kernel to begin with. How this is related to the greater systemd is beyond me.

laumars 12y ago
The occasion that springs to mind wasn't an altercation between Lennart and Linus specifically. But it was about systemd: http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA (there's probably better write ups on this argument, Phoronix was just the first link that came up when Googling for the /proc/cmdline Linus systemd rant)
- the_why_of_y 12y ago
  That is interesting... so basically the systemd developers wanted to turn the generic parameter kernel command line parameter "debug" into something that could be easily used by admins to find out why their system won't boot (whether the problem is in the kernel or in userspace), and got flamed to a crisp by kernel developers who want to keep using "debug" to debug their kernel code because they've always done it that way, and couldn't care less about helping actual end users.
  - laumars 12y ago
    You have things backwards. It was the systemd developers that didn't want the debug command line to be used against systemd. They were the ones who filed the patch to prevent the debug command line from reaching user space (/proc/cmdline) and it was the kernel developers (well, Linus specifically) who refused to patch and demanded that systemd cleaned up their debugging output so that 1) it didn't crash Linux (which it was doing previously), and 2) the output was more useful to end users for debugging.
    - thwarted 12y ago
      Yeah, that was an odd fix. Then /proc/cmdline doesn't reflect what the actual kernel command line was, thereby making debugging more opaque. The sane option, which the kernel developers suggested, was that systemd namespace pre-boot options it takes from the kernel command line, just like every kernel subsystem already does.
  - scintill76 12y ago
    The kernel devs are mad that flipping a kernel debug switch (on the kernel command-line, after all!), causes a userspace program to change its behavior, to the point that "the system becomes undebuggable on a dracut/systemd system" (kernel dev's words; apparently systemd spews a bunch of debug info into dmesg.) If you're going to say it's the kernel's fault, it's ultimately because they ever exposed the kernel cmdline to userspace, as something like this was inevitable. > got flamed to a crisp by kernel developers who want to keep using "debug" to debug their kernel code because they've always done it that way If their reports can be believed, they literally can't get work done (if it involves turning on debug in the kernel of a systemd installation), so it's far from some petty turf war or irrational hatred for change. Even if they should change, you seem to take it for granted, that they should have to change their kernel workflow, based on what something in userspace does -- why?
    - the_why_of_y 12y ago
      The kernel command line has the "quiet" option, which has for many years been used by user-space to display a fancy graphical progress bar instead of 100s of lines of text; "debug" is just the inverse of that. There was also some bug in systemd that caused it to log an excessive amount of assertion failures into some kernel buffer, which was in fact a really bad bug and was probably the reason for the whole flame-fest; naturally this bug has been fixed. But think about it: is it likely that the whole distracting turf war over the "debug" flag helped in getting the actual bug fixed as fast as it could have been? The reason why I would prefer to have systemd respect the "debug" flag, even if it means that kernel developers have to learn a new workflow, is that there are a lot more system administrators than kernel developers out there, and (on average) the kernel hackers have lots more expertise than the admins. So if a system has problems booting there should be a simple, short, generic parameter to get some verbose logging enabled, that can be used to track down the problem whether it's in the kernel or in user space, which you can't know beforehand of course. The kernel developers may be understandably unhappy about the change, but once they get over their initial reaction using a different parameter for kernel-only debugging is really quite trivial at their level of competence.
      - 12y ago

laumars 12y ago

The occasion that springs to mind wasn't an altercation between Lennart and Linus specifically. But it was about systemd: http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA (there's probably better write ups on this argument, Phoronix was just the first link that came up when Googling for the /proc/cmdline Linus systemd rant)

the_why_of_y 12y ago
That is interesting... so basically the systemd developers wanted to turn the generic parameter kernel command line parameter "debug" into something that could be easily used by admins to find out why their system won't boot (whether the problem is in the kernel or in userspace), and got flamed to a crisp by kernel developers who want to keep using "debug" to debug their kernel code because they've always done it that way, and couldn't care less about helping actual end users.
- laumars 12y ago
  You have things backwards. It was the systemd developers that didn't want the debug command line to be used against systemd. They were the ones who filed the patch to prevent the debug command line from reaching user space (/proc/cmdline) and it was the kernel developers (well, Linus specifically) who refused to patch and demanded that systemd cleaned up their debugging output so that 1) it didn't crash Linux (which it was doing previously), and 2) the output was more useful to end users for debugging.
  - thwarted 12y ago
    Yeah, that was an odd fix. Then /proc/cmdline doesn't reflect what the actual kernel command line was, thereby making debugging more opaque. The sane option, which the kernel developers suggested, was that systemd namespace pre-boot options it takes from the kernel command line, just like every kernel subsystem already does.
- scintill76 12y ago
  The kernel devs are mad that flipping a kernel debug switch (on the kernel command-line, after all!), causes a userspace program to change its behavior, to the point that "the system becomes undebuggable on a dracut/systemd system" (kernel dev's words; apparently systemd spews a bunch of debug info into dmesg.) If you're going to say it's the kernel's fault, it's ultimately because they ever exposed the kernel cmdline to userspace, as something like this was inevitable. > got flamed to a crisp by kernel developers who want to keep using "debug" to debug their kernel code because they've always done it that way If their reports can be believed, they literally can't get work done (if it involves turning on debug in the kernel of a systemd installation), so it's far from some petty turf war or irrational hatred for change. Even if they should change, you seem to take it for granted, that they should have to change their kernel workflow, based on what something in userspace does -- why?
  - the_why_of_y 12y ago
    The kernel command line has the "quiet" option, which has for many years been used by user-space to display a fancy graphical progress bar instead of 100s of lines of text; "debug" is just the inverse of that. There was also some bug in systemd that caused it to log an excessive amount of assertion failures into some kernel buffer, which was in fact a really bad bug and was probably the reason for the whole flame-fest; naturally this bug has been fixed. But think about it: is it likely that the whole distracting turf war over the "debug" flag helped in getting the actual bug fixed as fast as it could have been? The reason why I would prefer to have systemd respect the "debug" flag, even if it means that kernel developers have to learn a new workflow, is that there are a lot more system administrators than kernel developers out there, and (on average) the kernel hackers have lots more expertise than the admins. So if a system has problems booting there should be a simple, short, generic parameter to get some verbose logging enabled, that can be used to track down the problem whether it's in the kernel or in user space, which you can't know beforehand of course. The kernel developers may be understandably unhappy about the change, but once they get over their initial reaction using a different parameter for kernel-only debugging is really quite trivial at their level of competence.
    - 12y ago