Re: RFC: A reduced Linux network stack for small systems

[Alexei Starovoitov]

On Tue, May 6, 2014 at 1:00 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/