lkml.org 
[lkml]   [2014]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: RFC: A reduced Linux network stack for small systems
From
On Tue, May 6, 2014 at 1:00 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> not quite. I'm saying: no extra optimizations, no GCC changes.
>> Compile kernel as-is. Most functions have a stub for mcount() already.
>> Use it to track whether kernel function was called or not.
>> Collect this data in userspace (as perf already does), add few
>> more functions that had 'notrace' attribute on them, and feed this into
>> special linker that unpacks existing vmlinux, throws away cold functions,
>> relocates the rest and here you have tiny vmlinux without recompilation.
>
> That's very difficult for networking code. How would you know you
> exercised all the corner cases in the TCP stack? And you wouldn't
> want a remotely exploitable system because some important error
> handler is missing.

I think removing functions by linker will get you the same level of bugs
then stubbing functions out by kconfig.
One doesn't have to use profile feedback to remove them.
Either linker or config approach seems pretty much equivalent to me.
In case of config, a lot of patches need to be reviewed and maintained.
In case of linker the embedded setup can pick and choose without burdening
mainline. If it crashes, it will be clear that it crashed due to call to removed
function. Iteratively you'll get a setup that works for this
particular application.
Both approaches are full of potential crashes, undoing removal is much
easier with linker. Best solution is to add memory and don't mess with .text.

> I agree it may work for some other subsystems.
>
> -Andi


\
 
 \ /
  Last update: 2014-05-06 23:21    [W:0.653 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site