On the sickness of our community

Posted Oct 14, 2014 9:33 UTC (Tue) by mpr22 (subscriber, #60784)
In reply to: On the sickness of our community by anselm
Parent article: On the sickness of our community

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.

to post comments

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.