On 01/26/2013 10:13 AM, Roman Bogorodskiy wrote:
Third round of porting netdev stuff to FreeBSD.
A few words on virNetDevTapCreate() changes since the previous
review:
- it seems that there's no way to avoid iteration over
possible interface names, at least I wasn't able
to find fucntions for that available from userland
- replaced 255 with IF_MAXUNIT, which appears to be a
proper constant for that
- if we requested to set tapfd, open the device before
rename while we still have the original interface name,
as the device entry stays the same, i.e. if we rename
tap0 to vnet0, it would be still accessible at /dev/tap0,
not /dev/vnet0. Fail if the open() failed
Roman Bogorodskiy (4):
FreeBSD: implement virNetDevExists() and virNetDevSetName().
Make virNetDevSetupControl() public.
FreeBSD: implement virNetDevSetMAC() and virNetDevGetMTU().
FreeBSD: implement virNetDevTapCreate() and virNetDevTapDelete().
src/libvirt_private.syms | 1 +
src/util/virnetdev.c | 81 ++++++++++++++++++++++++++++++---
src/util/virnetdev.h | 6 +++
src/util/virnetdevtap.c | 114 +++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 192 insertions(+), 10 deletions(-)
ACK (however I hope someone else can take a glance too for those
libvirt specific things that I'm still getting used to)
Just a nit in the series before this would get pushed - virnetdev.c has
some extra spacing in the function header for virNetDevSetupControl() on
the second line:
+virNetDevSetupControl(const char *ifname,
+ struct ifreq *ifr)
^^^^
My Google search found IF_MAXUNIT (0x7fff) being much larger than 255!
Not sure if/where this could/should be documented within the libvirt
pages. That is by not requesting a specific vnet# interface name could
have performance implications because of the serial nature of the
algorithm to find an available name especially if there are numerous tap
interfaces already defined. Although I'm not quite sure where that
would occur as I'm still learning where things are myself!
John