Re: [RFC PATCH] xen/arm: Rebranding dom0less feature

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 7/1/23 11:13, Luca Fancellu wrote:
> > On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> >
> > On 30/06/2023 10:12 am, Luca Fancellu wrote:
> > > The "dom0less" feature was intended to be the feature where a domU
> > > domain could be launched without the control domain (Dom0)
> > > intervention, however the name seems to suggest that Dom0 cannot
> > > be part of the configuration, while instead it's a possible use case.
> > >
> > > To avoid that, rename the "dom0less" configuration with the name
> > > "hyperlaunch", that is less misleading.
> > >
> > > Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx>
> > > ---
> > > This is an RFC to get the feeling of the community about the name
> > > change, for now it's everything in one patch just to see how it
> > > will look like, if there is interest on proceeding into it, I can
> > > split in more commit.
> > Have you discussed this with Dan and Chris at all?  You haven't even
> > CC'd them.
> No, this rename idea started from a chat during the summit, anyway Julien
> promptly add them to the CC, because I forgot.
No worries and thank you for considering and taking the time to do this 
RFC. It is greatly appreciated that there is a strong willingness to 
have dom0less and hyperlaunch merged.
> > While there is a lot of end-goal in common between the dom0less and
> > hyperlaunch, and that the name dom0less is deeply misleading,
> > hyperlaunch is specifically not this.
> Yes Hyperlaunch is more than this, however as I said, with this RFC I would like
> to ear opinions, @Daniel @Christopher could it be a proper name for the dom0less
> feature?
As Andy has alluded, hyperlaunch is meant to provide a flexible means to 
handle domain construction at boot to meet a wide range of possible use 
cases. One of those use cases is dom0less, so yes, ultimately what 
dom0less does today will be achievable under hyperlaunch. Our intended 
approach to align the two implementations is one that is meant to be 
minimally disruptive, since dom0less is considered a supported 
(SUPPORT.md) capability. As mentioned, we are greatly appreciative to 
the openness to adopt the name, but a big concern I personally have is 
the confusion it could cause a general user. A blanket rename would end 
up with two documents in the docs tree that provide two different 
explanations of hyperlaunch and two different device tree definitions. 
So I think a more measured approach should be considered here.
> If this patch makes things more difficult for the Hyperlunch serie, I’m ok to 
> drop it,
> my only aim was just to find a less misleading name for the feature.
What I would like to suggest as a good first step would be an update to 
the dom0less document. Provide a note at the beginning that points to 
the hyperlaunch design doc as a more general approach that will 
eventually subsume dom0less. This would provide a gentler transition for 
exist users of dom0less.
If it is not too much, I would also ask, please have a look at the 
design for boot modules in the series Christopher just posted. The 
design pulls from the work done by dom0less and expanded upon it. I 
major step into merging the two capabilities will be to have a common 
set of structures. Once those are in place, we can move to a common 
device tree representation, and at that point we would be fairly close, 
if not at the point of a formal merger of between the two.
Thank you and please let me know what you think!

v/r,
dps

> Cheers,
> Luca
>
> > ~Andrew