On Mon, Mar 12, 2018 at 04:18:35PM +0100, Erik Skultety wrote:
> Hi,
> I'd like to add 2 more GSOC ideas to our wiki page, but I'd like to get some
> opinions whether you think these might even be appropriate GSOC project
> candidates.
> #1
> Support wildcard with log filters
> Enhance the log filters format to allow specifying a wildcard, i.e. <level>:*
> Currently, libvirt admin interface allows (among other things) runtime tuning
> of daemon log settings with the exception of setting the global log priority.
> The main reason for not having an API to get/set the global log priority is 
> that
> the same effect that setting global log level would have can be achieved with
> using log filters only which in terms of logging control provide us with more
> granularity. However, in order to achieve the same effect using filters only,
> one would end up with a filter similar to this:
> 1:access 1:daemon 1:conf 1:cpu 1:libvirt 1:locking 1:logging 1:network
> 1:nwfilter 1:util
> Therefore, we should enhance the format of a filter to allow us to simply use
> the following instead:
> 1:* other_filters

I think this is too small a bit of work - it is more like a bite-sized task for

> #2
> Extend node device driver's API set
> Modify the existing set (adjust/add) of APIs for node device driver in order 
> to
> provide similar functionality (conceptually) to other drivers.
> The node device driver is responsible for host device management. In most
> cases, this means that we're simply just report device's capabilities and 
> track
> its lifetime. This is enough for physical host devices, however, there are a
> few other virtualization features like NFV, NPIV, and MDEV where libvirt 
> should
> also be able to create such virtual devices. Currently, libvirt is only able 
> to
> create transient (temporary config) NPIV/vHBA devices, so besides having 
> support
> for creating virtual functions and mediated devices on feature-capable 
> physical
> device we also need to be able to store persistent configuration of such 
> virtual
> devices.
> Besides extending the existing set of APIs, this will also require a certain
> amount of refactor of our current code base. Not all of the changes mentioned
> above are absolutely necessary to finish the project successfully.

This sounds like a viable idea - well defined scope and not too hard

|: 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 :|

libvir-list mailing list

Reply via email to