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