> On 3 Jul 2023, at 21:54, P S <pairsp...@gmail.com> wrote: > > > >> On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fance...@arm.com> wrote: >> >> >> >>> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabell...@kernel.org> 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.coop...@citrix.com> 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.fance...@arm.com> >>>>>>> --- >>>>>>> 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 :-) >> >>
