RE: [PATCH v3 2/4] docs, xen/arm: Introduce static heap memory

[Henry Wang <Henry.Wang@xxxxxxx>]

Hi Julien,

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> > I think I've addressed all comments from Julien regarding my series,
> 
> If it is not too late for you would you be able to resend your series
> without the 'address-cells'/'size-cells' change? This will give me the
> opportunity to have an other review today.

I will be off after resending this so you can have another look today.

> 
> > so I think I've got some bandwidth to do the clean-up patch tomorrow
> > after the agreement, unless someone would like to do it himself?
> 
> Renaming "xen,static-mem-..." is a bit tricky because they have been
> defined in Xen 4.16.
> 
> I couldn't find any support statement specific to the static memory
> feature. So it would technically fall under the "dom0less" section which
> is security supported.
> 
> That said, I don't think we can consider that the static memory feature
> is even supported because, until yesterday, the code wasn't properly
> handling request to balloon in/out. So I would view this is a tech
> preview (Could someone send a patch to clarify SUPPORT.MD)?

In current code, the static allocation is in SUPPORT.md as tech preview.

> 
> This would mean that would be that we could consider the binding
> unstable and we could do a straight renaming. That said, I can
> understand this may be undesirable.
> 
> If that's the case then we would need to keep the current binding as-is.
> So we would have two options:
>    1) Provide a new compatible so #address-cells #size-cells can be
> used. The current binding can be deprecated
>    2) Leave as-is and accept the difference
> 
> I don't have a strong opinion on which way to go. Whichever, it would be
> good to write down the rationale in the commit message of the "future"
> patch.
> 
> I would not block this series on the renaming for existing property
> (what matter is the new ones are consistent with the discussion). The
> renaming could be done afterwards. I would even say post the feature
> freeze on Friday because this could be considered as a bug fix (assuming
> you agree as the release manager :)).

Actually this is the one I want to discuss with you, I am good with considering
this clean-up patch as a bug fix.

Kind regards,
Henry

> 
> Cheers,
> 
> --
> Julien Grall