* Juan Quintela (quint...@redhat.com) wrote: > "Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote: > > >> Forget -b/-i. > >> > >> migration_set_parameter compression_threads 8 > >> > >> migrate <foo> > >> > >> We don't use compression_threads at all > >> > >> migrate_set_capability compress > >> > >> migrate <foo> > >> > >> Now, we use compression threads. > >> > >> So, compression_threads parameter is a parameter that is only used when > >> compress capability is enabled. > >> > >> Same for block migration. Block_incremental parameter is used only when > >> block migration capability is setup. No dependency check needed at all. > >> > >> Or I am losing something obvious here? > > > > Ah, you've made up a new rule > > Oops, I thought that was a rule on how things worked O:-) > > >- I don't think it's a bad rule > > but is it true? Do we always enable a capability before we use a > > parameter? I don't think so - I think the tls parameters don't have > > a capability. > > To use tls paramater, we need to use an url with tls, no? > > > My previous rule was just that if it was a bool it was a capability > > and you can have whatever dependencies you like there - or none. > > Dunno. > > If you think that we can document it (one way or another), I am for it. > > It is really weird that we both thought (reading) the interface that the > rules are different O:-)
Well I think that's because no one ever defined any rules! We just created parameters because we needed something that could take non-boolean values, but I don't think there's anything more about the structure of their use that's actually defined. Similarly, I don't think there's anything defined about the structure of capabilities. Dave > Later, Juan. -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
