From: Dave Wysochanski <dwysocha@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH] (6/11) re-introduce vg_read
Date: Tue, 25 Nov 2008 16:14:36 -0500 [thread overview]
Message-ID: <1227647676.8335.63.camel@localhost.localdomain> (raw)
In-Reply-To: <87vdud6sdm.fsf@eriador.mornfall.net>
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 parent reply other threads:[~2008-11-25 21:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-30 18:08 [PATCH] (6/11) re-introduce vg_read Petr Rockai
2008-11-24 3:59 ` Dave Wysochanski
2008-11-24 15:44 ` Petr Rockai
2008-11-25 21:14 ` Dave Wysochanski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1227647676.8335.63.camel@localhost.localdomain \
--to=dwysocha@redhat.com \
--cc=lvm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.