Re: [libvirt] (Dropping) OOM Handling in libvirt
On Mon, May 20, 2019 at 02:16:44PM +0200, Michal Privoznik wrote:
> <snip/>
One thing that I've realized was that we have the NSS plugin which currently
links statically with a small library that we build aside
(src/libvirt-nss.la). The plugin uses virHash, virObject, virString and some
other submodules of ours. If we replace our implementation with glib then
effectively every process that ever calls gethostbyname() will be
dynamically linking with glib/gobject/....
Don't know if it's a bad thing, just putting it out here to consider.
I'm not so worried about the fact that we're linking with more stuff
since glib etc will already be memory resident.
The fact that the stuff we link to will abort on OOM though will be
undesirable for an NSS module that can be loaded into every single
app on the host. Some of those apps may really want/need to be
safe wrt OOM and you can't easily opt-out of NSS modules per app.
The libvirt_nss.c file is only 700 lines long. Despite out cut down
static linking it still pulls in quite a bit of libvirt code.
This is probably a case where we'd need to make the NSS module use
only plain C library codes + json lib, with no abstraction from
libvirt or any other library.
We don't really need the portability benefits from either gnulib
or glib for NSS anyway, since it is a Linux specific framework.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|