All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	StefanoStabellini <stefano.stabellini@eu.citrix.com>
Cc: andrew.cooper3@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 1/2] xen: move perform_gunzip to common
Date: Thu, 13 Aug 2015 11:17:50 +0100	[thread overview]
Message-ID: <1439461070.23981.61.camel@citrix.com> (raw)
In-Reply-To: <55CC862C020000780009A924@prv-mh.provo.novell.com>

On Thu, 2015-08-13 at 03:57 -0600, Jan Beulich wrote:
> > 
> > > > On 13.08.15 at 11:28, <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 13 Aug 2015, Jan Beulich wrote:
> > > > > > On 12.08.15 at 18:15, <stefano.stabellini@eu.citrix.com> wrote:
> > > > On Wed, 12 Aug 2015, Jan Beulich wrote:
> > > > > > > > On 12.08.15 at 16:47, <stefano.stabellini@eu.citrix.com> 
> > > > > > > > wrote:
> > > > > > @@ -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.
> > > 
> > > Hmm, the way it is used on x86 makes it quite architecture specific
> > > (namely because of the assumption that the size is also in said
> > > place for non-gz compression methods). I'd therefore prefer code
> > > duplication over code sharing here. 
> > 
> > Actually after seeing the size and quality of the resulting patches, I
> > am starting to feel the same way.
> > 
> > In terms of code changes, I was thinking that the best result would be
> > moving the "boilerplate" code from xen/arch/x86/bzimage.c to
> > xen/common/inflate.c, see below, then the interface would become just
> > perform_gunzip and gzip_check. But I guess you wouldn't want inflate.c
> > to be modified, right?
> 
> Yes, unless really unavoidable.
> 
> > Alternatively we could move it to a new file, let's call it gunzip.h,
> > that would #include "inflate.c", so:
> > 
> > bzimage.c -- #include --> gunzip.h -- #include --> inflate.c
> > 
> > And again we just leave the perform_gunzip and gzip_check calls in
> > bzimage.c.  What do you think?

How about putting perform_gunzip and gzip_check into a new gunzip.c which
includes inflate.c?

  reply	other threads:[~2015-08-13 10:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-12 14:47 [PATCH 0/2] support compressed kernels on ARM64 Stefano Stabellini
2015-08-12 14:47 ` [PATCH 1/2] xen: move perform_gunzip to common Stefano Stabellini
2015-08-12 15:14   ` Jan Beulich
2015-08-12 16:15     ` Stefano Stabellini
2015-08-13  6:29       ` Jan Beulich
2015-08-13  9:28         ` Stefano Stabellini
2015-08-13  9:57           ` Jan Beulich
2015-08-13 10:17             ` Ian Campbell [this message]
2015-08-13 10:27               ` Jan Beulich
2015-08-12 14:47 ` [PATCH 2/2] xen/arm: support compressed kernels Stefano Stabellini
2015-08-12 15:03   ` Ian Campbell
2015-08-12 15:20     ` Julien Grall
2015-08-12 15:22     ` Stefano Stabellini
2015-08-12 15:27       ` Julien Grall
2015-08-12 15:35       ` Jan Beulich
2015-08-12 15:40         ` Stefano Stabellini
2015-08-12 15:43       ` Ian Campbell
2015-08-12 15:09   ` Julien Grall
2015-08-12 16:35   ` Andrew Cooper
2015-08-12 17:00     ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1439461070.23981.61.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.