Add SCTP_SUPPORT handling to config.mk.

[markj]

Summary

In a subsequent change I will disable building of sctp.ko when
SCTP_SUPPORT is not defined.

[tuexen]

Would it make sense to build the sctp kernel module only if SCTP_SUPPORT is defined and SCTP is not defined? It does not make sense to build be module on a kernel which it can't load because of missing prerequisites. But also does not make sense to build the module if you can't load it because SCTP support is already in the kernel. Or do you envision SCTP and SCTP_SUPPORT being mutually exclusive options?

[markj]

In D25402#560407, @tuexen wrote:

Would it make sense to build the sctp kernel module only if SCTP_SUPPORT is defined and SCTP is not defined? It does not make sense to build be module on a kernel which it can't load because of missing prerequisites. But also does not make sense to build the module if you can't load it because SCTP support is already in the kernel.

Yes, that is what my WIP patch does, following the example of IPSEC.

Or do you envision SCTP and SCTP_SUPPORT being mutually exclusive options?

I don't think they need to be mutually exclusive. If anything I think it would make more sense to have the SCTP option depend on SCTP_SUPPORT, like we have with INVARIANTS and INVARIANTS_SUPPORT. For now I'm still following the example of IPSEC/IPSEC_SUPPORT, though.

[tuexen]

In D25402#560424, @markj wrote:

In D25402#560407, @tuexen wrote:

Would it make sense to build the sctp kernel module only if SCTP_SUPPORT is defined and SCTP is not defined? It does not make sense to build be module on a kernel which it can't load because of missing prerequisites. But also does not make sense to build the module if you can't load it because SCTP support is already in the kernel.

Yes, that is what my WIP patch does, following the example of IPSEC.

Great. Thanks for the clarification. I must admit that I'm not familiar with the way how IPSEC works. Thanks is why I'm asking...

Or do you envision SCTP and SCTP_SUPPORT being mutually exclusive options?

I don't think they need to be mutually exclusive. If anything I think it would make more sense to have the SCTP option depend on SCTP_SUPPORT, like we have with INVARIANTS and INVARIANTS_SUPPORT. For now I'm still following the example of IPSEC/IPSEC_SUPPORT, though.

So is the way IPSEC/IPSEC_SUPPORT works like I described above? The module is build if and only if it is loadable (which means the kernel is built with support for the module, but the complete code is not build into the kernel (avoiding references to SCTP and SCTP_SUPPORT). I perfectly fine with SCTP_SUPPORT (without SCTP) means that the kernel can work with the module and it is build; SCTP requires SCTP_SUPPORT and means the code goes statically into the kernel and module is not build. I don't think the defines in the code use that semantic right now, but that can be changed. I just want to know how it is intended to work...

[markj]

In D25402#560424, @markj wrote:

In D25402#560407, @tuexen wrote:

I don't think they need to be mutually exclusive. If anything I think it would make more sense to have the SCTP option depend on SCTP_SUPPORT, like we have with INVARIANTS and INVARIANTS_SUPPORT. For now I'm still following the example of IPSEC/IPSEC_SUPPORT, though.

So is the way IPSEC/IPSEC_SUPPORT works like I described above? The module is build if and only if it is loadable (which means the kernel is built with support for the module), but the complete code is not build into the kernel (avoiding references to SCTP and SCTP_SUPPORT). I perfectly fine with SCTP_SUPPORT (without SCTP) means that the kernel can work with the module and it is build; SCTP requires SCTP_SUPPORT and means the code goes statically into the kernel and module is not build. I don't think the defines in the code use that semantic right now, but that can be changed. I just want to know how it is intended to work...

What I think makes the most sense is that we build the module unless both SCTP and SCTP_SUPPORT are not defined. John pointed out that ipsec.ko only gets built if IPSEC_SUPPORT is defined _and_ IPSEC is not defined. But this is because of some IPSec-specific issues. So:

SCTP+SCTP_SUPPORT: build module, module is not loadable
SCTP_SUPPORT: build module, module is loadable
SCTP: In my patches, this is the same as SCTP+SCTP_SUPPORT. In the tree I see a lot of #if defined(IPSEC) || defined(IPSEC_SUPPORT) so I guess this is how IPSec works as well. If you have no objection, I will keep it that way for consistency.
none: no module, sctp.ko cannot be loaded

[tuexen]

In D25402#561490, @markj wrote:

In D25402#560424, @markj wrote:

In D25402#560407, @tuexen wrote:

I don't think they need to be mutually exclusive. If anything I think it would make more sense to have the SCTP option depend on SCTP_SUPPORT, like we have with INVARIANTS and INVARIANTS_SUPPORT. For now I'm still following the example of IPSEC/IPSEC_SUPPORT, though.

So is the way IPSEC/IPSEC_SUPPORT works like I described above? The module is build if and only if it is loadable (which means the kernel is built with support for the module), but the complete code is not build into the kernel (avoiding references to SCTP and SCTP_SUPPORT). I perfectly fine with SCTP_SUPPORT (without SCTP) means that the kernel can work with the module and it is build; SCTP requires SCTP_SUPPORT and means the code goes statically into the kernel and module is not build. I don't think the defines in the code use that semantic right now, but that can be changed. I just want to know how it is intended to work...

What I think makes the most sense is that we build the module unless both SCTP and SCTP_SUPPORT are not defined. John pointed out that ipsec.ko only gets built if IPSEC_SUPPORT is defined _and_ IPSEC is not defined. But this is because of some IPSec-specific issues. So:

SCTP+SCTP_SUPPORT: build module, module is not loadable
SCTP_SUPPORT: build module, module is loadable
SCTP: In my patches, this is the same as SCTP+SCTP_SUPPORT. In the tree I see a lot of #if defined(IPSEC) || defined(IPSEC_SUPPORT) so I guess this is how IPSec works as well. If you have no objection, I will keep it that way for consistency.
none: no module, sctp.ko cannot be loaded

I'm fine with it. I just wanted to understand what the code is intended to do. That way it is clear in the future, how to insert new #ifdefs if needed. Thanks for the clarification.