125c5e52a5
We have several possible ways of communicating with other entities. We use sockets to communicate with the host and other network sites, but also in a different context to communicate "spliced" channels to a namespace. We also use a tuntap device or a qemu socket to communicate with the namespace or guest. For the time being these are just defined implicitly by how we structure things. However, there are other communication channels we want to use in future (e.g. virtio-user), and we want to allow more flexible forwarding between those. To accomplish that we're going to want a specific way of referring to those channels. Introduce the concept of a "passt/pasta interface" or "pif" representing a specific channel to communicate network data. Each pif is assumed to be associated with a specific network namespace in the broad sense (that is as a place where IP addresses have a consistent meaning - not the Linux specific sense). But there could be multiple pifs communicating with the same namespace (e.g. the spliced and tap interfaces in pasta). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
27 lines
610 B
C
27 lines
610 B
C
/* SPDX-License-Identifier: GPL-2.0-or-later
|
|
* Copyright Red Hat
|
|
* Author: David Gibson <david@gibson.dropbear.id.au>
|
|
*
|
|
* Passt/pasta interface types and IDs
|
|
*/
|
|
#ifndef PIF_H
|
|
#define PIF_H
|
|
|
|
/**
|
|
* enum pif_type - Type of passt/pasta interface ("pif")
|
|
*
|
|
* pifs can be an L4 level channel (sockets) or an L2 level channel (tap device
|
|
* or qemu socket).
|
|
*/
|
|
enum pif_type {
|
|
/* Invalid or not present pif */
|
|
PIF_NONE = 0,
|
|
/* Host socket interface */
|
|
PIF_HOST,
|
|
/* Qemu socket or namespace tuntap interface */
|
|
PIF_TAP,
|
|
/* Namespace socket interface for splicing */
|
|
PIF_SPLICE,
|
|
};
|
|
|
|
#endif /* PIF_H */
|