Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-26 Thread Ian Jackson
Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels"): > Anyway - I guess we should continue from v3, which I hope to post > later this morning. Thanks, yes. I just wanted to reply to one bit of this: > My initial attempt to avoi

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Jan Beulich
On 25.01.2021 18:30, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd > compressed kernels"): >> On 25.01.2021 17:17, Ian Jackson wrote: >>> I think we had concluded not to print a warning ? >> >> Yes. Even in the

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Ian Jackson
The quoted-reply part of this message may be going off into the weeds. Feel free to ignore it, or parts of it, if you think you can make progress without disabusing me of what I think are my misunderstandings... Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compr

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Jan Beulich
On 25.01.2021 17:17, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd > compressed kernels"): >> On 25.01.2021 15:53, Ian Jackson wrote: >>> Well how about passing "true" for the fourth argument then ? >> &g

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Ian Jackson
I have a feeling we may be talking at cross purposes rather too much. Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels"): > On 25.01.2021 15:53, Ian Jackson wrote: > > Well how about passing "true" for the fourth argume

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Jan Beulich
On 25.01.2021 15:53, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd > compressed kernels"): >> On 25.01.2021 14:51, Ian Jackson wrote: >>> I mean, the parts where you examine libzstd_PKG_ERRORS. >> >> The only

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Ian Jackson
Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels"): > On 25.01.2021 14:51, Ian Jackson wrote: > > I mean, the parts where you examine libzstd_PKG_ERRORS. > > The only thing I make use of is it being (non-)empty. Do you > really t

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Jan Beulich
On 25.01.2021 14:51, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd > compressed kernels"): >> On 25.01.2021 12:30, Ian Jackson wrote: >>>> As far as configure.ac goes, I'm pretty sure there is a better (

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Ian Jackson
Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels"): > On 25.01.2021 12:30, Ian Jackson wrote: > >> As far as configure.ac goes, I'm pretty sure there is a better (more > >> "standard") way of using PKG_CHECK_MO

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Jan Beulich
On 25.01.2021 12:30, Ian Jackson wrote: > Hi. Thanks for this. Firstly, RM hat: this is the tools half of zstd > decompression support which I think is a blocker for the release. So > I am going to waive the last posting date requirement. Therefore, > > Assuming it's committed this week: > >

Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-25 Thread Ian Jackson
Hi. Thanks for this. Firstly, RM hat: this is the tools half of zstd decompression support which I think is a blocker for the release. So I am going to waive the last posting date requirement. Therefore, Assuming it's committed this week: Release-Acked-by: Ian Jackson Secondly, I think it

[PATCH v2.5 1/5] libxenguest: support zstd compressed kernels

2021-01-21 Thread Jan Beulich
This follows the logic used for other decompression methods utilizing an external library, albeit here we can't ignore the 32-bit size field appended to the compressed image - its presence causes decompression to fail. Leverage the field instead to allocate the output buffer in one go, i.e.