[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 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.

> @@ -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? 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.

Jan


_______________________________________________
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®.