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

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

> On 3 Jul 2023, at 21:54, P S <pairspace@xxxxxxxxx> wrote:
> 
> 
> 
>> 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"?

I’m ok as long as the Arm maintainer are happy with it

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