Shedding old architectures and compilers in the kernel

Posted Feb 27, 2018 15:21 UTC (Tue) by doublez13 (guest, #122213)
In reply to: Shedding old architectures and compilers in the kernel by moltonel
Parent article: Shedding old architectures and compilers in the kernel

Because by completely dropping support for older compilers, we're able to get rid of chucks of code needed only to support them.

Shedding old architectures and compilers in the kernel

Posted Feb 27, 2018 19:11 UTC (Tue) by moltonel (subscriber, #45207) [Link] (4 responses)

Yes, I know that's the whole point of droping support.

But my comment was about documenting the more nuanced support: the LKML thread shows that documenting a single minimum version hides a lot of useful info ("gcc foo is supported but you'll miss out on bar"). Detailed support docs should help both users of old tools and support-droping efforts by developers.

Shedding old architectures and compilers in the kernel

Posted Mar 1, 2018 4:16 UTC (Thu) by xtifr (guest, #143) [Link]

Sounds like a great idea. How soon can you have a first draft for us to check out?

Shedding old architectures and compilers in the kernel

Posted Mar 3, 2018 19:19 UTC (Sat) by nix (subscriber, #2304) [Link] (2 responses)

That's... not really useful, because nobody ever reads the documentation. The kernel's build dependencies have been documented in the same place for decades (they moved from Documentation/Changes to Documentation/process/changes.rst recently, but left a symlink), yet when I've added build dependencies there I see many questions from people who encounter build failures because of the lack of those dependencies but never consider even looking to see if the kernel's build-deps are documented anywhere, let alone looking to see if they changed.

And that's something as obvious as a build failure when turning on a new feature: i.e. doing something active, intentionally. Nobody will think to look in documentation if a *lack* of upgraded compiler causes a failure (or, worse, a silent change in semantics). Nobody.

Shedding old architectures and compilers in the kernel

Posted Mar 3, 2018 22:14 UTC (Sat) by moltonel (subscriber, #45207) [Link] (1 responses)

The logical conclusion to "nobody ever reads the doc" is that the docs should be deleted, to reduce the maintenance burden. Maybe your premise is true for users. I guess it is true for me, a desktop user getting his build tools and kernel sources from a distro.

But it's clearly not true for (some) kernel devs, since they are discussing raising the minimum version (which is only defined in the docs). Since the goal is to get rid of old workarounds and to be sure that certain features are available, wouldn't it make sense for devs to document what those features and workarounds are ? So that devs know what can be removed from the kernel after raising requirements to this or that ? Wouldn't a short "version X brings you Y" table speed things up for the next reqs update discussion, compared to a single "version X required" statement ?

Shedding old architectures and compilers in the kernel

Posted Mar 4, 2018 14:06 UTC (Sun) by nix (subscriber, #2304) [Link]

My premise is from, uh, kernel developers working for a major Linux distributor (unnamed to save their blushes). Maybe the problem is that nobody ever *rereads* Documentation/Changes after they read it once, since the assumption is that after your latest pull the deps are unchanged. (I am guilty here too, of course. So is everyone who builds a lot of kernels.)

But if kernel devs don't read the things, I see no reason to assume that anyone else will.