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

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>> 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,
> 
> Thanks Daniel!
> 
> 
>> 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.
> 
> At the moment we have a concrete problem with explaining dom0less and
> hyperlaunch to potential new users. Using two different names for a
> similar feature on arm and x86 causes confusion. It is hurting Xen as a
> solution. Personally I already had to switch to use the word
> "hyperlaunch" for everything in my users-facing presentations.
> 
> At the summit, we discussed that it would be a good idea to use a single
> name to refer to both features on arm and x86. Given that "dom0less"
> causes additional issues because it makes people think that there is no
> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
> 
> We don't need to 100% align the two implementations and data structures.
> This is not for engineers that are going to look at the specifications
> and improve them. This is for users/customers of Xen that are trying to
> understand what the hypervisor enables them to do. We need to be able to
> show users architecture slides with the same name and explanation on
> both ARM and x86.
> 
> I am sure that Daniel and Christopher remember, but for the others on
> this email thread, the name "hyperlaunch" was born exactly to be that:
> the one name to cover both features on ARM and x86 even if they have a
> different implementation. Appended an old email for reference.
> 
> Also I agree with Daniel that we need to be careful about the two docs
> under docs/. I think he is right we need to add a paragraph explaining
> the history and a pointer to the other document. Something like:
> 
> "Dom0less is the name that was used when initially introducing the
> feature on ARM. Then, the "dom0less" name was retired in favor of
> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
> align with x86 (where a similar feature was called hyperlaunch from the
> start)."

I’m fully ok to add a section like this pointing to the Hyperlaunch design.

@Daniel and @Christopher would it be ok for you or the changes in the serie
are going to be problematic for your future work? In the end it’s just a 
mechanical
rename, so I guess we just need to agree on naming conventions.

Cheers,
Luca

> 
> 
> ---
> 
> Subject: [RFP] Overarching name for dom0less and DomB
> 
> Greetings,
> 
> At the DeviceTree/DomB meeting it was proposed that a new, larger
> overarching name under which DomB and dom0less would be covered. There
> was a general openness to the idea. As such, since Christopher and
> myself are in the midst of finalizing the design document for DomB we
> felt it might be better to see if a name could be selected which we
> could use in the design doc in lieu of DomB. As always naming things is
> hard, but after some brainstorming we believe we have arrived at a
> decent name, μLaunch (micro-Launch or uLaunch).
> 
> ---
> 
> μLaunch became hyperlaunch few days after, and the rest was history :-)