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