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
On Wed, Oct 14, 2015 at 03:34:52PM -0400, 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
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
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_STRIPE_UNIT as a 4byte
int, what happens if someon
12 matches
Mail list logo