On the sickness of our community

Posted Oct 14, 2014 8:52 UTC (Tue) by anselm (subscriber, #2796)
In reply to: On the sickness of our community by johill
Parent article: On the sickness of our community

It can. It just takes preparation and time. ”debug” on the command line isn't one of the most widely used-by-other-software parts of the kernel UI (not ABI as there's nothing “binary” about it) to begin with. It's probably more feasible to change the behaviour of “debug” than it is to change the behaviour of open(2).

Having said that, the original issue was a misunderstanding about what “debug” on the kernel command line actually means. Some people insist that it applies to the kernel only while others claim it applies to other basic system components like plymouth or systemd, too. Since it had never been documented properly it is difficult to figure out who is right and who is wrong here; it does make some sense to be able to tell early-boot software to log debug messages, and possibly to do so using one convenient command line parameter rather than half a dozen. The actual problem at hand started because systemd contained a faulty assertion that caused it to write loads of stuff to the “dmesg” buffer. That assertion was promptly fixed.

Anyway, one interesting observation is that in the bug report we find

Kay, Please go die in a fire along with Lennart. Your type is the cancer that is killing any semblence of usability Linux once had.

and

Kay and Lennart: please just go away, disappear from the FOSS community, we don't need you and your crap.

and

Hopefully the FOSS community will wake up and eject these fucktards.

with nothing remotely similar being said by systemd developers, who remain commendably calm and try to get the discussion back on a technical track. If that is supposed to be an example of how systemd developers are rude and pushy while kernel developers are polite, sensitive and deferential, then there seems to be a bit of cognitive dissonance going on here.

to post comments

On the sickness of our community

Posted Oct 14, 2014 9:33 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (2 responses)

The kernel command line is absolutely an ABI; it is used not only by humans, but by other programs (bootloaders write it, and userspace programs running on top of the kernel read it). That one of the defined properties of the kernel command line is that it looks like text does not make it cease to be an ABI, any more than the defined inputs or outputs for various nodes in /proc being formatted text makes those not an ABI.

On the sickness of our community

Posted Oct 14, 2014 10:22 UTC (Tue) by johannbg (guest, #65743) [Link] (1 responses)

Last time I checked there was no stability promises with regards to the kernel commandline ( not sure it ever can be ) so relying on it in any shape or form cannot be trusted thus you are on your own if something breaks and as far as I know things get added and deprecated all the time.

Cleaning this up ( yes it's mess not just the generic part ) takes preparation, time and adoption period ( an time where both the new and the old parameters syntax are valid )

Once the kernel community has established clear and well defined kernel command line naming policy and clean things up accordingly it could well decide to declared it as an "ABI" but now it is an complete utter mess.

As things currently stand you cannot see a difference between an kernel command line parameter that is bios related,kernel related, pci related etc. Things are being separate by an underscore, an dot. an minus. o_O

The old ( none existing ) naming scheme might have worked back in the day when there were just 5 kernel parameters and everybody kept a local copy of the kernel man pages in their back pocket for what these meant and what they where supposed to do and where they belong but this is the 21 century and things have considerably grown since then so an clear policy like bios.<foo>, kernel.<foo> pci.<foo> etc is much needed to clearly define which parameter belongs where and to avoid anykind of misinterpretation of those parameters.

If the kernel community does not want to clean this up it should not insult and complain when stuff breaks as an result of that.

This whole "debug drama" would not have taken place if these things had been thoroughly thought through from the beginning but I guess people had better things to do at that time and now it's being indicated that they cannot fix it as an result of that. <sigh>

On the sickness of our community

Posted Oct 14, 2014 11:18 UTC (Tue) by anselm (subscriber, #2796) [Link]

Last time I checked there was no stability promises with regards to the kernel commandline

I don't think there are formal stability promises for anything in the kernel. It's just that the kernel people have a good track record of not changing things without cause, and they're trying to keep things that way.

The kernel command line is an example of what happens if people get to add stuff in an ad-hoc manner and with little regard to present consistency or compatibility down the road. No wonder nobody knows exactly what the “debug” option is supposed to mean when it was probably added at 2am in the morning someday in 1993 to solve some immediate issue and never actually thought through. As far as kernel commandline parameters go, we're now basically stuck with them in the same way that we're stuck with “cut -d“, “awk -F”, and “sort -t”.

Could the “debug drama” have been handled better by everyone concerned? Sure. But piling all the blame on Kay Sievers doesn't do it for me.

On the sickness of our community

Posted Oct 16, 2014 20:32 UTC (Thu) by flussence (guest, #85566) [Link]

Can you explain the purpose behind the three quotes you've chosen to post in this context, and whether any of those people have any connection whatsoever to either systemd or kernel development?

Without that context, I interpret the second half of that post as a textbook example of strawman fallacy.