[prev in list] [next in list] [prev in thread] [next in thread]
List: lvm-devel
Subject: Re: [lvm-devel] [PATCH] (6/11) re-introduce vg_read
From: Dave Wysochanski <dwysocha () redhat ! com>
Date: 2008-11-25 21:14:36
Message-ID: 1227647676.8335.63.camel () localhost ! localdomain
[Download RAW message or body]
On Mon, 2008-11-24 at 16:44 +0100, Petr Rockai wrote:
> Dave Wysochanski <dwysocha@redhat.com> writes:
> > It is a little confusing have a vg_read_for_update() (only intended for
> > WRITE) and a generic vg_read() (that allows both READ/WRITE) in the same
> > API. Should we have "vg_read_for_update()" (WRITE) and
> > vg_read_for_query()" (READ) or something like that?
> Well, is it? I tend to think about it like "select", and "select for update" in
> SQL, although the analogy is not 100 % correct, I know. But I intended
> vg_read_for_update as a convenience function that obviously points out that you
> intend to update the VG (as opposed to just read it).
>
> But, I suppose it's a bikeshed point. We however still want a generic vg_read,
> for the iterator functions (in toollib) which need to pass a flag to
> differentiate the read/write case.
>
I liked the explicit read_for_update idea.
My main concern is app writer confusion. Shouldn't they expect a
uniform API (one API for obtaining read access, one for write access)?
Don't you think someone not familiar with internals of LVM will ponder
this?
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic