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

[P S <pairspace@xxxxxxxxx>]

> On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@xxxxxxx> wrote:
> 
> 
> 
>> 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.

_If_ this text is added, please include links/references to the Hyperlaunch 
wiki page and Hyperlaunch design docs.

> @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.

Please see the history of trademark litigation about the use of symbolic names 
to reference similar-but-different artifacts.  It is much easier to use the 
same name to refer to entirely different objects. Historically, confusion 
arises when a name is used in similar contexts.

There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version 
-1"? 

How about renaming dom0less to "Hyperlaunch Lite"?

Rich

> 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 :-)
> 
>