Shrinking the kernel with an axe

Posted Feb 9, 2018 7:42 UTC (Fri) by pclouds (guest, #76590)
Parent article: Shrinking the kernel with an axe

> those attempts were welcomed with a cold headwind that left me alone in the woods with frozen fingers.

Poor Nico. I hope you keep trying and get these in mainline eventually.

Shrinking the kernel with an axe

Posted Feb 9, 2018 15:56 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link] (3 responses)

Getting changes like these in mainline requires time, money, energy, probably a sufficient number of interested users, and possibly overcoming some non-technical obstacles. Likewise for long-term maintenance of the simpler code paths after mainline integration. With the lukewarm reception of the initial attempts, I can understand why he's not eager to do it :)
But I'm still glad that he's spending time making this series of quality articles for LWN.

Shrinking the kernel with an axe

Posted Feb 9, 2018 17:03 UTC (Fri) by npitre (subscriber, #5680) [Link] (2 responses)

Thank you for your comment. Your observation is quite right, especially about interested users. The rest normally comes along with them.
These articles are a way for this work not to completely go to waste.

Shrinking the kernel with an axe

Posted Feb 9, 2018 21:27 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link] (1 responses)

Your reasoning for reducing the footprint of the Linux kernel through simplified versions of the layers, which would enable Linux to target platforms it currently can't for technical reasons, and arguably help further lower the market share of the (partially) closed-source offerings (with GPL'ed software, even, though that's getting less popular), made perfect sense to me. It's probably even more relevant now, with the advent of efforts such as NERF... Hopefully, the simplified code would also provide lower attack surface.

But how can individual users, or scattered groups thereof, efficiently signal their interest for e.g. tinified versions of the standard Linux kernel features - or, as far as I'm concerned, various features, fixes and improvements known from PaX/grsecurity, and other people have other interests - to the powers that be among the main Linux kernel maintainers ?

Maintaining, evolving, testing out of tree Linux kernel code (theoretically less political interference, more technical work, but also clearly zero decision weight) over the long term is known to be exhausting - especially when done unpaid or under-paid on one's free time, as happens to most FLOSS maintainers...

Shrinking the kernel with an axe

Posted Feb 10, 2018 2:19 UTC (Sat) by npitre (subscriber, #5680) [Link]

The word I get from microcontroller vendors (the marketing guys that is -- the engineers disagree) is that they have no demand for Linux support. What individual users or groups should do is to signal their interest to their vendor. If the market demand is there then I will no longer be the only one being paid to work on this, and upstream inclusion would be easier to advocate. Those articles are nice for sharing my knowledge and experience, but this is also an attempt at stirring up some interest or I'll eventually be paid to work on something else.

If the market demand is there, then mainline acceptance becomes a purely technical issue. So far in my experience I always managed to sort out technical issues with upstream maintainers, but when they ask if the added maintenance burden is justified by an actual user base then they have a point.

I think the issues with PaX/grsecurity are different. I'm not familiar enough with it to venture further comments though.