[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] xen: move perform_gunzip to common



On Wed, 12 Aug 2015, Jan Beulich wrote:
> >>> On 12.08.15 at 16:47, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > --- a/xen/common/decompress.c
> > +++ b/xen/common/decompress.c
> > @@ -16,6 +16,8 @@ int __init decompress(void *inbuf, unsigned int len, void 
> > *outbuf)
> >           (!memcmp(inbuf, "\037\213", 2) || !memcmp(inbuf, "\037\236", 2)) )
> >          return gunzip(inbuf, len, NULL, NULL, outbuf, NULL, error);
> >  #endif
> > +    if (gzip_check(inbuf, len))
> > +        return perform_gunzip(inbuf, len, NULL, NULL, outbuf, NULL, error);
> 
> Afaict it would be appropriate for this to replace the #if 0 block the
> end of which is seen here as context.

Yes, I'll make the change.


> > @@ -31,8 +33,15 @@ typedef int decompress_fn(unsigned char *inbuf, unsigned 
> > int len,
> >   * dependent).
> >   */
> >  
> > -decompress_fn bunzip2, unxz, unlzma, unlzo, unlz4;
> > +decompress_fn perform_gunzip, bunzip2, unxz, unlzma, unlzo, unlz4;
> >  
> >  int decompress(void *inbuf, unsigned int len, void *outbuf);
> >  
> > +static inline unsigned long output_length(char *image, unsigned long 
> > image_len)
> 
> Neither of the callers gets moved out of bzimage.c - why does this
> function need to move?

We'll use it on arm.


> And if it's unavoidable I'd suggest naming it
> with a meaningful prefix and using the opportunity to constify the
> first parameter. And while unlikely for it to not get inlined, retaining
> the original __init would seem necessary to avoid build failures which
> would result if this didn't get inlined.

I'll do.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.