Re: [libvirt] [patch v3 2/2] add inotify handler to qemu driver

On Thu, May 22, 2014 at 02:07:32 +0000, chen.fan.fnst(a)cn.fujitsu.com wrote: > On Thu, 2014-05-15 at 11:25 +0200, Jiri Denemark wrote: > > On Wed, May 07, 2014 at 18:11:50 +0800, Chen Fan wrote: > > > we don't expect to reload 'migrate_uri' with restarting libvirtd everytime while > > > updating the URI, so adding inotify handler to reload 'migrate_uri' configuration > > > without restarting libvirtd, it will be also helpful for virt-manager to get > > > 'migrate_uri'. > > > > NACK, if we ever want configuration to be automatically reloaded when > > configuration file changes (which I seriously doubt, SIGHUP is the > > standard way of reloading configuration files), we certainly would not > > want to do it this hacky way and only for one specific option. Not to > > mention that the content of virQEMUDriverConfig must not change, a > > completely new structure has to be created with the changed values. > > > Hi Jiri, > thanks for reminding me, actually, I knew the virQEMUDriverConfig > without lock protect to reload is wrong. except that I think there are > some options in virQEMUDriverConfig can be reloaded. as you said, If > we want to reload them, Do we must create a new structure to save the > changes, then we must use 'lock' to make code thread safe and override > the qemuDriverCfg values everywhere while we use them. right? > or are there any other ideas? virQEMUDriverConfig is immutable so the structure returned by virQEMUDriverGetConfig(qemu_driver) must never be changed. You have to create a copy of it, update the values in the new structure, take a driver lock, unref the original driver->config and put the new pointer to driver->config. This way, any code that already got virQEMUDriverConfig pointer will be using the old value and all calls to virQEMUDriverGetConfig will return the updated configuration. The old one will be freed when its last user unrefs it. But anyway, we should not be updating the config whenever the configuration file changes. We should rather do that in qemuStateReload. However, I'm not sure what to do if there are options that just cannot be changed while libvirtd is running. Applying some changes while ignoring others when SIGHUP is sent to libvirtd would certainly lead to confusion.

Jirka