RE: [PATCH v1] block/rbd: Add support for layered encryption

[Or Ozeri]

I tried casting to non-const and it seems to work. Changed in v3 now.
I did not know that a const modifier could simply be cast out :)

> -----Original Message-----
> From: Ilya Dryomov <idryomov@gmail.com>
> Sent: 15 November 2022 14:00
> To: Or Ozeri <ORO@il.ibm.com>
> Cc: qemu-devel@nongnu.org; qemu-block@nongnu.org; Danny Harnik
> <DANNYH@il.ibm.com>
> Subject: [EXTERNAL] Re: [PATCH v1] block/rbd: Add support for layered
> encryption
> 
> On Sun, Nov 13, 2022 at 11:16 AM Or Ozeri <ORO@il.ibm.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Ilya Dryomov <idryomov@gmail.com>
> > > Sent: 11 November 2022 15:01
> > > To: Or Ozeri <ORO@il.ibm.com>
> > > Cc: qemu-devel@nongnu.org; qemu-block@nongnu.org; Danny Harnik
> > > <DANNYH@il.ibm.com>
> > > Subject: [EXTERNAL] Re: [PATCH v1] block/rbd: Add support for
> > > layered encryption
> > >
> > > I don't understand the need for this char* array.  Is there a
> > > problem with putting the blob directly into
> > > luks_all_opts->passphrase just like the size is put into luks_all_opts-
> >passphrase_size?
> > >
> >
> > luks_all_opts->passphrase has a const modifier.
> 
> Hi Or,
> 
> That's really not a reason to make a dynamic memory allocation.  You can just
> cast that const away but I suspect that the underlying issue is that a const 
> is
> missing somewhere else.  At the end of the day, QEMU allocates a buffer for
> the passphrase when it's fetched via the secret API -- that pointer should
> assign to const char* just fine.
> 
> Thanks,
> 
>                 Ilya