[CRIU] Re: [RFC 0/4] Lets try PB again
Cyrill Gorcunov
gorcunov at openvz.org
Fri Jul 6 08:58:18 EDT 2012
On Fri, Jul 06, 2012 at 04:50:46PM +0400, Pavel Emelyanov wrote:
> On 07/06/2012 04:35 PM, Cyrill Gorcunov wrote:
> > On Fri, Jul 06, 2012 at 04:21:25PM +0400, Pavel Emelyanov wrote:
> >>
> >> Is there a way to unpack an object into a static buffer rather than
> >> allocating one dynamically?
> >
> > Yes, previously I've been using 16K stack for that, I can bring it back ;)
> >
> > +#define pbimg_write_obj(__fd, __object, __type, __get_packed_size, __pack)
> > +({
> > + u8 ___buf[KILO(16)];
> > + u32 ___size = __get_packed_size(__object);
> > + int ___ret = -1;
> >
> > that is from previous versions. If buffer is too small we will ge error.
> > But in most case 16K is more than enough ;)
>
> No, I meant a bit different thing. Instead of
>
> FooEntry *foo;
>
> foo = foo_entry__unpack();
> ...
> foo_entry__free_unpacked();
>
> write
>
> FooEntry foo;
>
> foo_entry__unpack_on_staack(&foo);
>
> Is it possible? If no, then OK, let's proceed with this approach.
And yes and no ;) It depends on type of message we use in .proto file.
Some messages such as FdinfoEntry do not have pointers inside their
"structure" generated by PB and we can "unpack it into stack
variable". But in general case this will be error (I even think that
I've made an error by copying unpacked structure into stack variable,
one day we might change .proto file, the generated structure will
have pointers to dynamically allocated members and we will get
use-after-free error).
> >> That's too big for a macro. Turn it into a macro + outlined function.
> >
> > I've been trying, but the problem is that PB compiler generates pack/unpack
> > prototypes with argument typed and I can't use some abstract function which
> > has void* types as arguments, gcc complains. So I switched to macros.
>
> Well, I think for _that_ case it's OK to use very abstract casting
> like this (*)() ;)
Hmm ;)
Cyrill
More information about the CRIU
mailing list