[PATCH] (6/11) re-introduce vg_read

[PATCH] (6/11) re-introduce vg_read

[Petr Rockai]

Hi,

this patch gets us back a function called vg_read, but this time it also does
locking -- by default it grabs a read lock, as vg_read_for_update should be
used when write lock is desired.

Yours,
   Petr.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvm2-lvmlib-new-vg_read.diff
Type: text/x-diff
Size: 3807 bytes
Desc: lvmlib-vg_read.diff
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20081030/e9b15a03/attachment.bin>
-------------- next part --------------

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation

[PATCH] (6/11) re-introduce vg_read

[Dave Wysochanski]

On Thu, 2008-10-30 at 19:08 +0100, Petr Rockai wrote:
> Hi,
> 
> this patch gets us back a function called vg_read, but this time it
> also does
> locking -- by default it grabs a read lock, as vg_read_for_update
> should be
> used when write lock is desired.
> 
> Yours,
>    Petr.
> 

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?

[PATCH] (6/11) re-introduce vg_read

[Petr Rockai]

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.

Yours,
   Petr.

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation

[PATCH] (6/11) re-introduce vg_read

[Dave Wysochanski]

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?