From: Tony Asleson <tasleson@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH] RFC: lvm2app: Add thin and thin pool lv creation
Date: Thu, 02 May 2013 17:24:44 -0500 [thread overview]
Message-ID: <5182E7AC.1060903@redhat.com> (raw)
In-Reply-To: <51824A5E.5010603@redhat.com>
On 05/02/2013 06:13 AM, Zdenek Kabelac wrote:
> Dne 29.4.2013 21:20, Tony Asleson napsal(a):
>> +lv_create_params_t lvm_lv_params_create_thin(const vg_t vg, const
>> char *pool_name,
>> + const char *lvname, uint64_t size)
>
> Hmmm - here the vg doesn't remain unmodified - we use it's memory pool
> for lvcp - so I'd prefer to use it here without 'const'
In this case having the const or not actually doesn't matter to the
compiler as we have a typedef'd structure pointer and thus the const is
meaningless. However, from a documentation standpoint I agree that the
const should be removed.
I'm actually thinking we should get rid of the typedef struct pointers
so that we can actually use const correctly and have it enforced by the
compiler. However, this would break existing user code.
>> +int lvm_lv_params_skip_zero_get(lv_create_params_t params)
>
>
> add const for '_get()'
Yeah good idea, but again not enforced by the compiler unless we ditch
typedef struct pointer. Which we can do for this newly created structure.
> Any API test case ?
I had a simple little C program to try this code out, but I haven't
created a test case. I wanted to see if this approach would be
acceptable to everyone before I go ahead and create the python bindings
and add this to the unit test case.
Zdenek, you appear good with this patch (except for a few minor
changes), how about everyone else?
Thanks,
Tony
next prev parent reply other threads:[~2013-05-02 22:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-29 19:20 [PATCH] RFC: lvm2app: Add thin and thin pool lv creation Tony Asleson
2013-05-02 11:13 ` Zdenek Kabelac
2013-05-02 22:24 ` Tony Asleson [this message]
2013-05-03 13:29 ` Zdenek Kabelac
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=5182E7AC.1060903@redhat.com \
--to=tasleson@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.