Add LinkDriver interface and Driver package

[brlbil]

This PR adds a LinkDriver interface that replaces the LinkInfo.Data and SlaveData fields and
adds Driver package with link drivers Bond, Netkit, and Veth that implement the LinkDriver interface.

Only these three drivers are implemented to demonstrate different kinds of link drivers and not complicate the PR.

Please take a look at the commit messages for individual changes.

Fixes: #216

[jsimonetti]

First off, thank you. This is very nice!

I have a few nits which I will comment on while I review. (Please allow me a day or two).

One thing i would like to discuss is rtnetlink.RegisterDriver.

First off, this function is not threadsafe. So it should have a very clear comment and documentation that it is very unwise to use after you Dial. I prefer it this way, instead of adding mutexes to protect it, since that would add considerable amount of locking.

Second, I think we should make a choice for the driver package. Currently it registers the drivers on init(), which I believe is fine, since it is what most people want. However, that does block consumer from registering their own driver, if it conflicts with drivers registered already.
So, either we move the driver registration away from init() to an explicit driver.LoadAll() function, or we leave it like this and add a rtnetlink.UnregisterDriver. The latter has my preference, and we could even hold off on that untill there is actual demand for such a function.

What do you think?

[brlbil]

Thanks for pointing these out.

Since rtnetlink.RegisterDriver relies on global variables, a global mutex would be needed for thread safety, which isn't ideal. Let's put a comment on this.

Initializing drivers with the second option makes more sense. We'll keep it this way and add rtnetlink.UnregisterDriver if necessary. Given the limited number of drivers, implementing most (or the most useful) should suffice, reducing the need for competing implementations. I am willing to work on adding other drivers later.

Another thing is that I have observed that the iproute2 tool does not send any attribute that is not initialized. I added the name behind a check because it was causing problems. It seems we could do the same for the values below. But I did not want to overcomplicate the PR. Am I missing anything here?

ae.Uint16(unix.IFLA_UNSPEC, 0)
if a.Name != "" {
	ae.String(unix.IFLA_IFNAME, a.Name)
}
ae.Uint32(unix.IFLA_LINK, a.Type)
ae.String(unix.IFLA_QDISC, a.QueueDisc)

I will make all of the changes after your review.

[jsimonetti]

I think I might have made your process a bit complicated by rebasing using github by accident. My appologies.

[jsimonetti]

Another thing is that I have observed that the iproute2 tool does not send any attribute that is not initialized. I added the name behind a check because it was causing problems. It seems we could do the same for the values below. But I did not want to overcomplicate the PR. Am I missing anything here?

ae.Uint16(unix.IFLA_UNSPEC, 0)
if a.Name != "" {
	ae.String(unix.IFLA_IFNAME, a.Name)
}
ae.Uint32(unix.IFLA_LINK, a.Type)
ae.String(unix.IFLA_QDISC, a.QueueDisc)

I believe you are correct. I have not had the need to address this though. I am fine with adding this to the PR

[brlbil]

While adding documentation to the drivers, I found a couple of issues and fixed them.

[jsimonetti]

Last nit I found. The rest is looking awesome!

[jsimonetti]

I am willing to work on adding other drivers later.
I am very much looking forward to more drivers!

@brlbil Thank you once again for this contribution!
I have cut a new release containing these changes.

[jsimonetti]

@brlbil I am keen to add some more drivers. Could you tell me how you found out what the layout of the linkinfo should be?
Perhaps point me at some docs you used, so I can look into other link types?

[brlbil]

@jsimonetti It is good to hear that. I want to work on it but I do not have much spare time these days. I have looked at other Golang Netlink library that implements drivers. It helps but there are some differences because it is designed differently. I have looked at the iproute2 tool but later I learned that it should not be taken as a reference implementation, the net namespace implementation that later changes. Lastly, I have looked at the kernel source https://elixir.bootlin.com/linux/latest/source/drivers/net and kernel patch messages.