On Fri, Oct 16, 2015 at 08:32:12AM +0300, Mykola Golub wrote:
> Thank you all for your comments! I will come back with PR and pull
> request.
Here it is: https://github.com/ceph/ceph/pull/6369
--
Mykola Golub
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of
Thank you all for your comments! I will come back with PR and pull
request.
--
Mykola Golub
On Thu, Oct 15, 2015 at 11:29:56AM -0700, Josh Durgin wrote:
> On 10/15/2015 06:45 AM, Sage Weil wrote:
> >On Thu, 15 Oct 2015, Mykola Golub wrote:
> >>On Thu, Oct 15, 2015 at 08:47:58AM -0400, Jason Dill
On 10/15/2015 06:45 AM, Sage Weil wrote:
On Thu, 15 Oct 2015, Mykola Golub wrote:
On Thu, Oct 15, 2015 at 08:47:58AM -0400, Jason Dillaman wrote:
But we don't need them to match between different platforms, no? Is
linking 64bit code with 32bit possible (supported)?
Also, for this particular (
On Thu, 15 Oct 2015, Mykola Golub wrote:
> On Thu, Oct 15, 2015 at 08:47:58AM -0400, Jason Dillaman wrote:
> > >
> > > But we don't need them to match between different platforms, no? Is
> > > linking 64bit code with 32bit possible (supported)?
> > >
> > > Also, for this particular (char*) case,
On Thu, Oct 15, 2015 at 08:47:58AM -0400, Jason Dillaman wrote:
> >
> > But we don't need them to match between different platforms, no? Is
> > linking 64bit code with 32bit possible (supported)?
> >
> > Also, for this particular (char*) case, length would actually be the
> > length of the string
>
> But we don't need them to match between different platforms, no? Is
> linking 64bit code with 32bit possible (supported)?
>
> Also, for this particular (char*) case, length would actually be the
> length of the string, not the pointer length. From my example:
>
> const char* journal_object_p
On Thu, Oct 15, 2015 at 08:05:07AM -0400, Jason Dillaman wrote:
> > > I am concerned about passing a void* + length to specify the option
> > > value since you really can't protect against the user providing data
> > > in the incorrect format. For example, if the backend treated
> > > RBD_OPTION_S
> > I am concerned about passing a void* + length to specify the option
> > value since you really can't protect against the user providing data
> > in the incorrect format. For example, if the backend treated
> > RBD_OPTION_STRIPE_UNIT as a 4byte int, what happens if someone
> > passes a 2- or 8-
On Wed, Oct 14, 2015 at 08:12:37PM -0700, Josh Durgin wrote:
> On 10/14/2015 12:34 PM, Jason Dillaman wrote:
> >In general, I like the approach.
> >
> >I am concerned about passing a void* + length to specify the option value
> >since you really can't protect against the user providing data in the
Original Message -
> > From: "Mykola Golub"
> > To: ceph-devel@vger.kernel.org
> > Cc: "Jason Dillaman" , "Josh Durgin"
> >
> > Sent: Wednesday, September 30, 2015 2:50:45 AM
> > Subject: CEPH_RBD_API: options on image crea
On 10/14/2015 12:34 PM, Jason Dillaman wrote:
In general, I like the approach.
I am concerned about passing a void* + length to specify the option value since
you really can't protect against the user providing data in the incorrect
format. For example, if the backend treated RBD_OPTION_STRIP
ssage -
> From: "Mykola Golub"
> To: ceph-devel@vger.kernel.org
> Cc: "Jason Dillaman" , "Josh Durgin"
> Sent: Wednesday, September 30, 2015 2:50:45 AM
> Subject: CEPH_RBD_API: options on image create
>
> Hi,
>
> It was mentioned several time
Hi,
It was mentioned several times eralier that it would be nice to pass
options as key/value configuration pairs on image create instead of
expanding rbd_create/rbd_clone/rbd_copy for every possible
configuration override.
What do you think about this API?
Introduce rbd_image_options_t and func
13 matches
Mail list logo
