[PATCH 06/13] Add lvm_vg_close().

[Dave Wysochanski <dwysocha@redhat.com>]

On Wed, 2009-02-04 at 12:11 -0500, Dave Wysochanski wrote:
> On Tue, 2009-02-03 at 00:45 +0100, Petr Rockai wrote:
> > Dave Wysochanski <dwysocha@redhat.com> writes:
> > > +void lvm_vg_close(vg_t *vg)
> > > +{
> > > +	if (vgname_is_locked(vg->name))
> > > +		unlock_vg(vg->cmd, vg->name);
> > > +}
> > Do we want to do reference counting in here? Might be moot if we don't allow
> > multiple opens. But contrary to what I said on IRC last time, it might be worth
> > to have proper lock upgrading procedure, and it would be sort of nice if that
> > could be achieved (for the user) by just calling the open function again on the
> > same VG, with write permission request. One use case is automated recovery,
> > which could be probably reformulated elegantly in terms of a lock upgrade.
> > 
> 
> Well, calling the open function again on the same VG would be a new
> interface that we'd have to explain so I'd lean against it.  Is there an
> example elsewhere we could point at?  If we went this route we'd need to
> keep a list of handles internally (we may end up needing this anyway for
> true handle validation) and then just pass back the same one.
> 
> Also I think Thomas was opposed to the lock upgrading.
> 

There are plenty of examples of lock upgrading though normally it's on
some sort of lock call, not an open.  I know we said we wanted to hide
the locking - maybe still possible.  But if we need lock upgrading it
might be clearer if we exposed a lock API directly.  *gasp*