<div dir="ltr">I see it more as a developer thing anyways. The users don't control software distribution and wont know/care about what the kernel requirement is. On the other hand people using the 2.6 such as debian or a embedded distributor will care and have the sense/knowledge to adjust accordingly.<div><br></div><div>On the other hand how much space are we talking? +20k? space is soo cheap even for embedded devices no one may even notice.</div><div><br></div><div>Maybe i should stop playing devils advocate.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 3:21 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/13/14 14:07, stephen Turner wrote:<br>
> Could you make it a menu/config flag similarly to how mv and cp are<br>
> added/removed?<br>
<br>
</span>I could, sure. I prefer to avoid burdening users with implementation<br>
details, but I suppose "support 2.6 kernels (requires suid root)" isn't<br>
too confusing.<br>
<br>
I do actually have a somewhat funny limitation that because I'm turning<br>
the menuconfig help text into ---help output for each command, I haven't<br>
currently got a way of explaining the config options in a way that<br>
DOESN'T wind up in the help text.<br>
<br>
(I could make it so lines starting with # don't go into the help text,<br>
but I'm balancing "do things automatically so people aren't bothered<br>
with details" against "magic things happen and I don't know why and am<br>
afraid to touch it". Beyond a certain point, I'm just plain reluctant to<br>
make the infrastructure more complicated unless absolutely necessary.)<br>
<br>
But in this case, I can explain it in the option name. :)<br>
<span class="HOEnZb"><font color="#888888"><br>
Rob<br>
</font></span></blockquote></div><br></div>