Toward a kernel maintainer's guide

Posted Nov 27, 2018 11:21 UTC (Tue) by mfuzzey (subscriber, #57966)
Parent article: Toward a kernel maintainer's guide

I think not all differences are equal.

Having different coding style rules for different parts of the kernel seems to be mostly a pain for everyone involved and I don't see any reasonable justification other than inertia.

On the other hand having somewhat different *processes* in terms of git trees, review rules, cycle time etc for different subsystems makes a lot more sense since maintainers do have different workflows and the "best" workflow is certainly also very dependent on the size of the subsystem (in terms of patch volume and number of developers).

Toward a kernel maintainer's guide

Posted Nov 27, 2018 15:29 UTC (Tue) by bfields (subscriber, #19510) [Link] (1 responses)

Having different coding style rules for different parts of the kernel seems to be mostly a pain for everyone involved and I don't see any reasonable justification other than inertia.

I can think of a few.

It takes effort to reach consensus: is a flame war on Christmas-tree declaration ordering really such a high priority?

People have more fun if they're given a little leeway.

The original Documentation/CodingStyle was 193 lines. Looks like currently Documentation/process/codingstyle.rst is 1079 lines. I wonder if people read it.

Toward a kernel maintainer's guide

Posted Nov 30, 2018 11:30 UTC (Fri) by ale2018 (guest, #128727) [Link]

Questions about reasons for doing x or y should always be welcome. In practice, they sound so marginal that readers just skip. Walking through the code together seems to be gone for good, or perhaps it's just not supported by the tools?

Toward a kernel maintainer's guide

Posted Nov 27, 2018 16:01 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

> Having different coding style rules for different parts of the kernel seems to be mostly a pain for everyone involved and I don't see > any reasonable justification other than inertia.

Empirically, this model has worked exceedingly well for a long time, hence, there's no reasonable justification to change it now just because that's unfamiliar to certain people. The only "pain" involved here is if style conventions are being enforced (or sometimes enforced, depending on the social situation) which aren't documented anywhere: There's no way someone who isn't already familiar with whatever petty regulations are considered important can divine knowledge about them. Hence, trainwrecks are guaranteed to occur: Someone's being annoyed that things were done differently despite "everybody knows that THIS is the proper colour for a bikeshed!", someone else finds himself suddenly stepping on hidden landmines despite painstakingly trying to do everything "in the right way".

As the paragraph above probably does (and certainly should) suggest, ideally, there would be no (or at least as few as possible) petty regulations at all. That different conventions about these can successfully coexist suggests that they aren't really necessary.

Toward a kernel maintainer's guide

Posted Nov 27, 2018 16:56 UTC (Tue) by mfuzzey (subscriber, #57966) [Link] (1 responses)

> Empirically, this model has worked exceedingly well for a long time, hence, there's no reasonable justification to change it now just because that's unfamiliar to certain people.

Yes, that's what I meant by inertia

>The only "pain" involved here is if style conventions are being enforced (or sometimes enforced, depending on the social situation) which aren't documented anywhere

Obviously if they aren't being enforced there is no pain :)
But if they are enforced, even if documented, it is a pain to those that work in multiple subsystems whereas those that only work in one probably never notice.

>As the paragraph above probably does (and certainly should) suggest, ideally, there would be no (or at least as few as possible) petty regulations at all. That different >
>conventions about these can successfully coexist suggests that they aren't really necessary.

Indeed, I completely agree with this. I wasn't suggesting that there should be a great "christmas tree debate" kernel wide. But that a rule should either be considered sufficiently important to be in the global CodingStyle or it should not exist.

Toward a kernel maintainer's guide

Posted Nov 27, 2018 22:59 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link]

> Indeed, I completely agree with this. I wasn't suggesting that there should be a great "christmas tree debate" kernel wide.
> But that a rule should either be considered sufficiently important to be in the global CodingStyle or it should not exist.

I don't think that's realistic, especially considering that some maintainers enforce coding style regulations which contradict what's written in the CodingStyle text (Patrick "This function is used only once. Get rid of it" McHardy being an example I personally encountered). OTOH, expecting outside contributors (or prospective outside contributors) to read throuhg a few years of a large number of high-volume mailing lists in order to discover "undocumented preferences" of over 1000 people is also not realistic. That's nothing but a camouflaged and guarded "No entry"-sign.

There must be a way for someone to determine which guidelines to follow, ie, a document listing them. Otherwise, one can only try to imitate how the other code is written and that's not a trusty guide: Some "style regulations" are actually not about style at all, they mandate functional differences, even to the point of requiring that code works in an unlogical way. Eg, some people are strongly convinced that all loops ought to be pre-test loops. I don't think so because the initial state is often known and testing a condition known be either true or false seems absurd to me. Nevertheless, I'd gladly follow such a rule if someone considered it important. But there's no way to infer this from code.