[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Henry,

On 07/09/2022 14:49, Henry Wang wrote:
-----Original Message-----
From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
But in any case we should only add one pair here for sure, as you say
the
only implication is to add a couple of 0 in the worst case.
I agree. The only drawback is the need to modify the already introduced
properties
to be coherent.
Agree, someone will need to do a pass on the whole doc which might be
easier with all things in.
Well, not only docs. If we decide to use a single pair of #address-cells and
#size-cells, then
we need to modify the code that expects different properties e.g.
xen,static-mem-{address/size}-cells.

Right I forgot that some parts are already in.
So we will need an extra patch to handle those.
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.
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)?
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 :)).
Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.