Quoting Arnaldo Carvalho de Melo:
| > +static u8 builtin_ccids[] = {
| > + DCCPC_CCID2, /* CCID2 is supported by default */
| > +#if defined(CONFIG_IP_DCCP_CCID3) || defined(CONFIG_IP_DCCP_CCID3_MODULE)
| > + DCCPC_CCID3,
| > +#endif
| > +};
|
| This considers only code that was already merged. What about a new CCID
| that is not yet merged? I guess the table should be managed at ccid
| module registration time... but that would prevent autoloading on
| demand, so I think that a sysctl interface that tells the DCCP core
| infrastructure which are the ccids that are available is better.
|
For each new CCID (which is likely to have a Kconfig option), the table would
need a new entry. The table is not necessary for autoloading, this is handled
separately, and there is flexibility in handling this. Currently (subsequent
patch), all advertised CCIDs are autoloaded at socket creation time (only if
this is the first socket call, not when the CCID modules are already loaded),
since ccid_new() is later only called in interrupt context. But this has the
nice byproduct that module loading is no longer needed - firing up the applications
at either end is sufficient to have everything loaded.
| Think also about an administrator deciding that even with the Linux
| kernel provided by his vendor containing modules for ccid2, 3, etc, he
| only accepts ccid3 or some other subset.
That is an interesting thought - defining system-wide policies. The above table is
much more primitive, it mainly is book-keeping to see what is there.
Do you mean something like net.ipv4.tcp_available_congestion_control ?
|
| We could have as default a table built with the modules we know at dccp
| core build time to be available in the current kernel build, but not
| prevent others from being added or existing ones to be disabled.
The disabling can also be done on a per-connection basis, via socket options.
One pain with the server-priority negotiation (and reason for the table) is that
when only a single value is used, then it only works if both ends happen to hit
the same value. One can exploit this fact to limit the choices.
| So I think we can start with what you provided and implement my
| suggestions later.
I am saving this in my todo folder and hope we can continue this thread.
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
