Shrinking the kernel with an axe

Posted Feb 9, 2018 21:27 UTC (Fri) by Lionel_Debroux (subscriber, #30014)
In reply to: Shrinking the kernel with an axe by npitre
Parent article: Shrinking the kernel with an axe

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...

to post comments

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.