(6/11) re-introduce vg_read
PATCH 1/1 (6/11) re-introduce vg_read
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 --------------
Signature · 6 lines
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 indentationPATCH 1/1 (6/11) re-introduce vg_read
Quoted 11 lines · 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, asvg_read_for_updateshould 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 1/1 (6/11) re-introduce vg_read
Quoted 4 lines · Dave Wysochanski
It is a little confusing have a
vg_read_for_update()(only intended for WRITE) and a genericvg_read()(that allows both READ/WRITE) in the same API. Should we have "vg_read_for_update()" (WRITE) andvg_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.
Signature · 6 lines
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 indentationPATCH 1/1 (6/11) re-introduce vg_read
Quoted 5 lines · Petr Rockai
Quoted 4 lines · Dave Wysochanski
It is a little confusing have a
vg_read_for_update()(only intended for WRITE) and a genericvg_read()(that allows both READ/WRITE) in the same API. Should we have "vg_read_for_update()" (WRITE) andvg_read_for_query()" (READ) or something like that?
Quoted 9 lines
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_updateas 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?