On 05/21/2010 01:21 PM, Eric Blake wrote:
On 05/21/2010 09:28 AM, Cole Robinson wrote:
Any interest in doing this with netlink instead? (I've got this "thing"
against parsing text files to get information if it can be retrieved via
a nice clean API). If so, I think I can whip up the equivalent code with
libnl calls, but probably not until later in the afternoon.
If I'm the only one who feels uneasy about parsing stuff out of /proc,
then I'm fine with that too.
My feeling is it depends on what else libnl buys us. A library
dependency for a single safety check doesn't seem worth it. If we use
the lib, we definitely don't want it to be optional, as debugging
network issues in the future shouldn't require asking 'is libvirt
compiled against libnl'.
Stefan just posted a patch series that would also add a dependency on
libnl for vepa; as long as we are using the library, we might as well
use it for more than one thing.
Yes and no. I just learned a few days ago that RHEL5 has libnl-1.0
installed, and it is incompatible with libnl-1.1 (different API, can't
be installed side by side).
On the other hand, netcf is already dependent on libnl (and because of
this will no longer build in EPEL5), so maybe that isn't an issue (ie
maybe we'll need to figure out how to fix it anyway - NetworkManager
fixes it by building a private copy of libnl-1.1 when building for RHEL5!)
I still prefer using libnl to /proc, but don't want to rush into
something that breaks something that can't stand being broken.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list