mbox series

[v3,00/15] zstd decompression for DomU-s + fallout / consolidation

Message ID 2db91183-a7de-0c43-2fef-feb3523ed19b@suse.com (mailing list archive)
Headers show
Series zstd decompression for DomU-s + fallout / consolidation | expand

Message

Jan Beulich Jan. 26, 2021, 9:46 a.m. UTC
Only patches 1 and 2 are strictly intended for 4.15, paralleling
the recent Dom0 side work (and re-using many of the files
introduced there, for the stubdom build), but ones up to at least
patch 6 may still want considering (and 4 already has a release
ack).

01: libxenguest: add get_unaligned_le32()
02: libxenguest: support zstd compressed kernels
03: xen/decompress: make helper symbols static
04: libxenguest: "standardize" LZO kernel decompression code
05: libxenguest: drop redundant decompression declarations
06: libxenguest: simplify kernel decompression
07: gunzip: drop INIT{,DATA} and STATIC
08: bunzip: replace INIT
09: unlzo: replace INIT
10: unlzma: replace INIT
11: unlz4: replace INIT
12: unxz: replace INIT{,DATA} and STATIC
13: unzstd: replace INIT{,DATA} and STATIC
14: xen/decompress: drop STATIC and INIT
15: unzstd: make helper symbols static

Jan

Comments

Ian Jackson Jan. 26, 2021, 12:05 p.m. UTC | #1
Jan Beulich writes ("[PATCH v3 00/15] zstd decompression for DomU-s + fallout / consolidation"):
> Only patches 1 and 2 are strictly intended for 4.15, paralleling
> the recent Dom0 side work (and re-using many of the files
> introduced there, for the stubdom build), but ones up to at least
> patch 6 may still want considering (and 4 already has a release
> ack).

Thanks.

> 01: libxenguest: add get_unaligned_le32()
> 02: libxenguest: support zstd compressed kernels

So these two are fine.

> 03: xen/decompress: make helper symbols static
> 04: libxenguest: "standardize" LZO kernel decompression code
> 05: libxenguest: drop redundant decompression declarations
> 06: libxenguest: simplify kernel decompression

I approve of cleanups of course.  But:

Which of these cleanups were posted before the LPD ?  I'm not
currently aware of any reason for a freeze exception here, so I think
those patches which didn't meet the LPD should wait.  Ones which *did*
meet the LPD should be considered on their merits.

If you could direct me to which those are I would be happy to review
them.

> 07: gunzip: drop INIT{,DATA} and STATIC

I release-nacked this because I saw you posted it with this Subject
  Subject: [PATCH v3 01/15] gunzip: drop INIT{,DATA} and STATIC
which made me think you were targeting it for 4.15.  If not then fine.

Thanks,
Ian.
Jan Beulich Jan. 26, 2021, 1:04 p.m. UTC | #2
On 26.01.2021 13:05, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH v3 00/15] zstd decompression for DomU-s + fallout / consolidation"):
>> Only patches 1 and 2 are strictly intended for 4.15, paralleling
>> the recent Dom0 side work (and re-using many of the files
>> introduced there, for the stubdom build), but ones up to at least
>> patch 6 may still want considering (and 4 already has a release
>> ack).
> 
> Thanks.
> 
>> 01: libxenguest: add get_unaligned_le32()
>> 02: libxenguest: support zstd compressed kernels
> 
> So these two are fine.
> 
>> 03: xen/decompress: make helper symbols static
>> 04: libxenguest: "standardize" LZO kernel decompression code
>> 05: libxenguest: drop redundant decompression declarations
>> 06: libxenguest: simplify kernel decompression
> 
> I approve of cleanups of course.  But:
> 
> Which of these cleanups were posted before the LPD ?  I'm not
> currently aware of any reason for a freeze exception here, so I think
> those patches which didn't meet the LPD should wait.  Ones which *did*
> meet the LPD should be considered on their merits.
> 
> If you could direct me to which those are I would be happy to review
> them.

All of them were posted after that date; only the Dom0 zstd
decompression part was ready in time. I view this entire
series as a logical extension to the earlier patches though.
I'm unsure anyway how new patches in a previously submitted
series would be treated in general; so far I've been under
the impression that if in doubt the series as a whole would
count, not every individual patch.

As said (still visible above) I'm not meaning to insist on
patches 3 and onwards to be taken. In fact it was you to
ask whether patch 3 would possibly want a freeze exception.
And you did give patch 4 a release ack already, based on it
containing a bug fix. (The latter is true of patch 6 as
well, btw.) Are you implying you withdraw that release ack
now?

While we're at this - how are bug fixes to be treated in
this two week window? Do they need a release ack too if
they did miss the LPD? I'm asking with specifically
"xen/include: compat/xlat.h may change with .config
changes" in mind, but there may be others, like Roger's
3-patch series posted today, which I intend to look at
rather sooner than later.

>> 07: gunzip: drop INIT{,DATA} and STATIC
> 
> I release-nacked this because I saw you posted it with this Subject
>   Subject: [PATCH v3 01/15] gunzip: drop INIT{,DATA} and STATIC
> which made me think you were targeting it for 4.15.  If not then fine.

FAOD - indeed it was a mistake of mine and was meant to
be 07/15.

Jan
Ian Jackson Jan. 26, 2021, 1:25 p.m. UTC | #3
Jan Beulich writes ("Re: [PATCH v3 00/15] zstd decompression for DomU-s + fallout / consolidation"):
> On 26.01.2021 13:05, Ian Jackson wrote:
> > I approve of cleanups of course.  But:
> > 
> > Which of these cleanups were posted before the LPD ?  I'm not
> > currently aware of any reason for a freeze exception here, so I think
> > those patches which didn't meet the LPD should wait.  Ones which *did*
> > meet the LPD should be considered on their merits.
> > 
> > If you could direct me to which those are I would be happy to review
> > them.
> 
> All of them were posted after that date; only the Dom0 zstd
> decompression part was ready in time. I view this entire
> series as a logical extension to the earlier patches though.
> I'm unsure anyway how new patches in a previously submitted
> series would be treated in general; so far I've been under
> the impression that if in doubt the series as a whole would
> count, not every individual patch.

I think as a general rule, I don't think "logical extensions" to
things posted before the LPD count.  But bugfixes, and smallish
changes necessary to make the rest of a previously-posted series are
OK.

> As said (still visible above) I'm not meaning to insist on
> patches 3 and onwards to be taken. In fact it was you to
> ask whether patch 3 would possibly want a freeze exception.
> And you did give patch 4 a release ack already, based on it
> containing a bug fix. (The latter is true of patch 6 as
> well, btw.) Are you implying you withdraw that release ack
> now?

I'm afraid that I don't keep all this state in my head.  I rely on
written materials.  Where the written materials in front of me seem
self-sufficient and don't contain unresolved references or things that
are confusing, I rely on what is in front of me being sufficient.
ISTM that the point of a summary mail like yours is to save us going
and rereading all the background each time.

None of the subject lines in your mail mentioned that these were
bugfixes.  So I'm afraid I had forgotten that.

I'm not withdrawing my release ack for anything.  But whena commit is
being justified for 4.15 because it is (or contains) a bugfix then it
would be really good if the bugfix were mentioned in the summary line.

> While we're at this - how are bug fixes to be treated in
> this two week window? Do they need a release ack too if
> they did miss the LPD?

No.

>  I'm asking with specifically
> "xen/include: compat/xlat.h may change with .config
> changes" in mind, but there may be others, like Roger's
> 3-patch series posted today, which I intend to look at
> rather sooner than later.

Things that are just bugfixes do not need a release ack at this stage.
Things that are a mixture should either get a release ack, or be
separated out in which case the bugfix part does not need a release
ack.  I am happy to give out (or decline) acks in cases of doubt.

I appreciate your looking at bugfixes as a priority, so thanks.

> >> 07: gunzip: drop INIT{,DATA} and STATIC
> > 
> > I release-nacked this because I saw you posted it with this Subject
> >   Subject: [PATCH v3 01/15] gunzip: drop INIT{,DATA} and STATIC
> > which made me think you were targeting it for 4.15.  If not then fine.
> 
> FAOD - indeed it was a mistake of mine and was meant to
> be 07/15.

NP.

I hope this explanation makes some kind of sense and sorry for the
confusion.

Ian.
Jan Beulich Jan. 26, 2021, 1:50 p.m. UTC | #4
On 26.01.2021 14:25, Ian Jackson wrote:
> I hope this explanation makes some kind of sense and sorry for the
> confusion.

It does and no, I don't think there was any confusion caused. Some
thinks merely needed clarifying, on my end at least. Thanks for
doing so.

Jan