Member main (int argc, char *argv[])

Start D-Bus once we support a mptcpd D-Bus API.

Call mptcpd_config_free() as soon we're done with reading the configuration, e.g. after the path manager has been initialized.

Should we daemonize the the mptcpd process the canonical way - fork() then orphan to make it owned by the 'init' process, among other steps - when systemd isn't used?

Make this daemon socket-activatable when using systemd.

Member MPTCP_PM_NAME_LEN

Remove this preprocessor symbol definition once support for path management strategy names are supported in the new generic netlink API.

Member mptcpd_addr_info::index

Will this value ever be zero, i.e. not set?

Member mptcpd_addr_info_get_id (struct mptcpd_addr_info const *info)

Good value to return on error?

Member mptcpd_idm::map

A hashmap may be overkill for this use case since a given host isn't likely to have many local IP addresses. Assuming that is the case, a simple O(n) based lookup on a linked list (e.g. l_queue) or an array should perform just as well.

Member mptcpd_nm_create (uint32_t flags)

As currently implemented, one could create multiple network monitors. Is that useful?

Member mptcpd_plugin_load (char const *dir, char const *default_name, struct l_queue const *plugins_to_load, struct mptcpd_pm *pm)

Determine if this is a performance bottleneck on 64 bit platforms since it is possible that connection IDs may end up in the same hash bucket due to the truncation from 64 bits to 32 bits in ELL's direct hash function, assuming unsigned int is a 32 bit type.

Member mptcpd_plugin_register_ops (char const *name, struct mptcpd_plugin_ops const *ops)

Should we return false if all of the callbacks in ops are NULL?

Member mptcpd_pm_add_subflow (struct mptcpd_pm *pm, mptcpd_token_t token, mptcpd_aid_t local_address_id, mptcpd_aid_t remote_address_id, struct sockaddr const *local_addr, struct sockaddr const *remote_addr, bool backup)

There far too many parameters. Reduce.

Member mptcpd_pm_cmd_ops::add_subflow )(struct mptcpd_pm *pm, mptcpd_token_t token, mptcpd_aid_t local_address_id, mptcpd_aid_t remote_address_id, struct sockaddr const *local_addr, struct sockaddr const *remote_addr, bool backup)

There far too many parameters. Reduce.

Member mptcpd_pm_create (struct mptcpd_config const *config)

As currently implemented, one could create multiple path manager instances? Is that useful?

Member mptcpd_token_t

These rely on MPTCP genl related implementation details in the kernel. Should we move these typedefs to <linux/mptcp.h>, e.g. 'typedef uint32_t mptcp_token_t'?