e96182e9c2
nl_link() performs a number of functions: it can bring links up, set MAC address and MTU and also retrieve the existing MAC. This makes for a small number of lines of code, but high conceptual complexity: it's quite hard to follow what's going on both in nl_link() itself and it's also not very obvious which function its callers are intending to use. Clarify this, by splitting nl_link() into nl_link_up(), nl_link_set_mac(), and nl_link_get_mac(). The first brings up a link, optionally setting the MTU, the others get or set the MAC address. This fixes an arguable bug in pasta_ns_conf(): it looks as though that was intended to retrieve the guest MAC whether or not c->pasta_conf_ns is set. However, it only actually does so in the !c->pasta_conf_ns case: the fact that we set up==1 means we would only ever set, never get, the MAC in the nl_link() call in the other path. We get away with this because the MAC will quickly be discovered once we receive packets on the tap interface. Still, it's neater to always get the MAC address here. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
25 lines
735 B
C
25 lines
735 B
C
/* SPDX-License-Identifier: GPL-2.0-or-later
|
|
* Copyright (c) 2021 Red Hat GmbH
|
|
* Author: Stefano Brivio <sbrivio@redhat.com>
|
|
*/
|
|
|
|
#ifndef NETLINK_H
|
|
#define NETLINK_H
|
|
|
|
enum nl_op {
|
|
NL_GET,
|
|
NL_SET,
|
|
NL_DUP,
|
|
};
|
|
|
|
void nl_sock_init(const struct ctx *c, bool ns);
|
|
unsigned int nl_get_ext_if(sa_family_t af);
|
|
void nl_route(enum nl_op op, unsigned int ifi, unsigned int ifi_ns,
|
|
sa_family_t af, void *gw);
|
|
void nl_addr(enum nl_op op, unsigned int ifi, unsigned int ifi_ns,
|
|
sa_family_t af, void *addr, int *prefix_len, void *addr_l);
|
|
void nl_link_get_mac(int ns, unsigned int ifi, void *mac);
|
|
void nl_link_set_mac(int ns, unsigned int ifi, void *mac);
|
|
void nl_link_up(int ns, unsigned int ifi, int mtu);
|
|
|
|
#endif /* NETLINK_H */
|