[haiku-development] moving classes from libbnetapi to libnetwork
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 16 Jan 2015 18:07:23 +0100
Hi,
Earlier today I pushed an implementation of getifaddrs. This is part of
an effort to update our fork of libbind to include the changes done by
the NetBSD team as part of the netresolv project
http://wiki.netbsd.org/individual-software-releases/netresolv/
I have merged their patches, which rewrite a great part of libbind. They
use some BSD-specific APIs in the implementation, which I could handle
using code from libbsd, libutil, and the freeBSD network compatibility
layer. The only exception is getifaddrs which is the last missing piece.
My implementation is based on BNetworkInterface, BNetworkRoster and
BNetworkAddress. These classes, however, are in libbnetapi. The reason
for this is that they are tied to the BeAPI, and we want libnetwork to
not link to libbe so ported applications and command line tools don't
need to initialize a full BeAPI context to use POSIX network functions.
I could rewrite getifaddrs to use sockets and ioctls directly, bt it
would replicate most of the code from these 3 classes. I would like to
avoid that.
It seems it should be possible to move the relevant parts of these
classes to libnetwork without having it depend on libbe. As far as I can
see:
- BNetworkAddress should compile without any problems, with
BNetworkAddressResolver.
- BNetworkInterface uses BMessages only in the AutoConfigure method
- BNetworkRoster needs to be split in two. The part that handles
"persistent networks" is BMessage-based.
I can move only the methods I need to libnetwork, essentially splitting
the implementation of these classes in two libraries. Or, I could split
the classes in two completely, in which case I need good names for the
two parts of each (BNetworkInterfacesRoster could be used for the
interfaces part of BNetworkRoster, but I'm not sure what to do with
BNetworkInterface). The libbnetAPI classes could then wrap the
libnetwork one to continue providing the same API.
Alternatively, I could move the code to getifaddrs, and implement these
classes using getifaddrs instead of sockets/ioctls. This is how it is
done for other parts of the libbnetapi currently, but I much prefer
writing the implementation in C++ and wrapping it in a C API.
What do you suggest?
--
Adrien.
Other related posts:
