In message <dtdko8$hh6$1@serpens.de>Michael van Elst writes
>jonathan@dsg.stanford.edu writes:
>
>>If I don't want to run IPv4, I don't have to build a special kernel;
>>GENERIC plus our boot-time /etc/rc.conf mechanisms can do that just
>>fine.  So, why should it be any different if I want to run lPv4, but
>>not IPv6?
>
>There is no necessity to have it different. But it is different.

Michael, I'm trying hard, but for the life of me I cannot understand
that sentence.  What are you trying to say?

[...snip quoted text]

>Maybe besides your point, but it is completely on topic unless
>you can disable IPSEC with our boot-time /etc/rc.conf mechanism.

<forced patience> Yes, of *course* our rc.conf mechanisms can disable
the actual *use* of IPsec, sure.  But the problem is that, last time
the idea to put IPsec in GENERIC came up here, even just *having*
IPsec configured into your kernel causes a noticeable performance hit.
Thor just repeated that claim in this thread.

And *that* is the reason for the prior consensus not to enable IPsec
in GENERIC kernels.  If you want to overturn that consensus, I think
you need to present rational arguments why the prior consensus was
wrong. I've looked, and I can't find any real attempt to do that.


>So far we need a special kernel to do IPSEC and we need a special
>kernel to remove IPv6.

>
>>>Making a GENERIC kernel support IPSEC initially is bad.
>>No, I never said that, so please don't put words in my mouth like
>>that. There's nothing wrong with supporting IPsec, *provided* doing
>>so doesn't impair other uses.  Unfortunately, as far as we know,
>>currently IPsec does impair other uses.
>
>Now that language is not simple enough for me. 

How can I make it simpler?  I personally can't imagine any technical
reason we'd not turn on IPsec in GENERIC if there was no downside,
since the upside (making in-kernel IPsec available in our default
installed kernel) is very clear.  But there *is* a long-standing
observation that there *IS* a downside to adding IPsec to GENERIC
kernels: overall networking performance of GENERIC kernels would
suffer, and that the performance penalty (relative to other *BSD
kernels which don't turn on IPsec in their default kernel) would show
up in benchmarks, and be widely publicized, to the overall detriment
of NetBSD.

>But your conclusion
>is that, as far as we know, putting IPSEC in GENERIC is bad.

No, not quite. That's not a conclusion, nor is it mine.
It's a widley-repeated statement. I'm just repeating it, as others
(Thor, for example) have already done in this thread.

There's also the consensus decision last time this idea came up, which
was that the known (or alleged) downside of slower networking
performance, outweighed the benefits of having IPsec in GENERIC kernels.

Once again, that's not *my* conclusion, but the consensus after
technical discussion.


[ .. discussion of  adding IPsec to GENERIC vs. adding hooks to disable IPv6,
   for those who want to disable it.]

Michael, I think we're talking at cross-purposes.

Adding hooks to our rc scripts, so as not to turn on IPv6. has no
signficiant impact on anyone. (It's one more shell variable in
/etc/defaults/rc.conf , and an extra test in already-existing "if"
clausees in 2 or 3 "if" statements that already exist in
/etc/rc.d/network.  Now I don't know for sure that that'll do
everything I need, but I can't for the life of me see why anyone would
object to adding one more clause to those "if" statements.

And if more work is required -- adding runtime sysctl knobs to force
errno returns of EOPNOTSUPP or EPROTONOSUPPORT for attempts to create
a socket of an administratively-disabled family -- then *I'm* the one
saying I'll put time into that.

>>>Making a GENERIC kernel as versatile as possible for newcomers is bad.
>>Indeed.  But versatility is in the eye of the beholder.
>
>So you agree that I understood you correctly.

No, I most certainly do not.


>>>Making a GENERIC kernel that spoils benchmarks is bad.
>
>>Yes, that's the consensus of the developers who've been maintaining
>>portions of the stack.  Not just me, but (if I recall correclty)
>>Thor, and Jason Thorpe, and others.  I'm not sure if Matt Thomas
>>commented or not.
>
>Apparently having GENERIC tuned to certain benchmarks is not
>on my priority list :)

Michael, can you explain why your personal priority list should
override the prior consensus on this issue?  To me, that seems to be
what you've been suggesting repeatedly in This thread. But maybe I am
misunderstanding. If that is what your're suggesting, then I for one
find that repugnant.

On the other hand, if it's not what you are suggesting, then can you
try to rephrase your suggestion, because (if your decision-tree ends
up here) I'm clearly not understanding you at all.