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

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

>>>> 
>>>> The "start VMs from Xen on boot" functionality is the *only* thing that a 
>>>> big chunk of the users of this functionality want;  referring to
>>>> it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of 
>>>> the functionality.
>>>> 
>>>> What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to 
>>>> refer to the full measured boot functionality?
>>> 
>>> I think this is the best way.
>>> 
>>> 
>>>> Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without 
>>>> the involvement of a domB), "Hyperlaunch Boot Domain /
>>>> Hyperlaunch domB" for a more general "domB" functionality, and 
>>>> "Hyperlaunch Measured Boot" for the full functionality (assuming there's
>>>> more to this than simply having a domB involved)?
>>> 
>>> 
>>> We need an overarching name to cover the feature "start VMs from Xen on
>>> boot" on both ARM and x86. From my understanding and from the original
>>> emails on the subject, the name "hyperlaunch" was it.
>>> 
>>> Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".  
>>> "Electric guitar" is new, "guitar" covers them both, but you sometimes need 
>>> a way to specify "acoustic".  Right now target configurations we're talking 
>>> about include:
>>> 
>>> 1. Booting all your domains directly from Xen using DT configurations
>>> 2. Booting a domB, which then executes some more complicated programmatic 
>>> configuration to launch VMs before disappearing
>>> 3. Doing full measured boot on the whole system using a domB.
>>> 
>>> If "Hyperlaunch" means 1-3, we not only need a way to specify that you're 
>>> talking about 3, but *also* a way to specify that you're talking about 1.  
>>> In the vast majority of cases for the foreseeable future are going to be 1. 
>>>  Additionally, we want to make sure that "Hyperlaunch" *actually* turns out 
>>> to mean 1-3, and not just 1.
>>> 
>>> The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool 
>>> but also is very descriptive: I haven't talked to people building these 
>>> systems, but it seems like saying, "The hypervisor launches VMs based on a 
>>> Device Tree passed to it at boot" will be immediately understood, and stick 
>>> in people's minds.
>> Personally, I like the name “Hyperlaunch DT”, because it tells me that we 
>> are launching VMs and the DT is involved, if I understood correctly the 
>> design,
>> it would be the same also on x86 (and in every architecture that will come 
>> later) so being “Hyperlaunch DT” an arch agnostic name makes it a good
>> candidate for phase out dom0less name and for the future when a common code 
>> will use the DT to launch VMs at Xen boot.
> 
> I assume that DT means Device-Tree here. If so, I find a name a bit 
> misleading because we are talking about the way to pass the configuration 
> rather than what the feature is doing.
> 
> My assumption here is that a DomB solution would still use the Device-Tree to 
> describe the domains.

The sentence below makes sense to me, “DT”, “domB/Boot/Boot Domain/BD”, 
“Measured Boot/MB” can do the work of distinguish the functionalities, even if 
the Device tree is involved in all of them.

>>>> Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without 
>>>> the involvement of a domB), "Hyperlaunch Boot Domain /
>>>> Hyperlaunch domB" for a more general "domB" functionality, and 
>>>> "Hyperlaunch Measured Boot" for the full functionality (assuming there's
>>>> more to this than simply having a domB involved)?


At least in my personal opinion, we have people that worked a lot more than me 
on this project so they can know better.


> 
> Cheers,
> 
> -- 
> Julien Grall