Handling of network namespace IDs
Thomas Haller
thaller at redhat.com
Tue May 16 03:05:07 PDT 2017
Hi,
On Mon, 2017-05-15 at 17:30 +0200, Andreas Fett wrote:
>
> There is a socket option NETLINK_LISTEN_ALL_NSID which can be set on
> a
> listening netlink socket to receive events from other network
> namespaces
> than the current one (ie /proc/self/ns/net).
>
> For this to work the other namespace(s) must be known by a network
> namespace id, which is a separate entity from the file descriptor
> that
> is used to enter that namespace.
>
> The ID can therefore only be used for a limited set of operations,
> most
> notably the monitoring of events as mentioned above. In addition
> there
> are messages to resolve a file descriptor to such an id and and to
> add
> an id given the file descriptor for a namespace.
>
> My Questions are:
> * Is there any ongoing work to integrate this into libnl?
No
> * Would there be interest to integrate this if I could provide
> patches?
Yes (if the patches make sense).
> * How would an API to integrate this look like?
It seems the core libnl-3.so library, doesn't really care about it.
You can already today get the file descriptor and set the socket
option. Probably it needs API to be able to access the namespace id of
a message.
For the other libraries like libnl-route-3.so, it seems complicated to
extend. Mainly, these libraries allow parsing and caching of objects
received from netlink.
Should the objects become aware of the namespace (and have it part of
their ID)? If not, you would need one cache per namespace.
best
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20170516/2f3acac9/attachment.sig>
More information about the libnl
mailing list