[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |