Hi, > On 6 Sep 2022, at 08:54, Julien Grall <jul...@xen.org> wrote: > > Hi Bertrand, > > On 06/09/2022 08:24, Bertrand Marquis wrote: >>> I agree with Julien: I prefer this proposal compared to the earlier one >>> by Bertrand and Rahul because I think it is a lot clearer and "ENHANCED" >>> should mean everything. Also, it makes it easier from a compatibility >>> perspective because it matches the current definition. >>> >>> But I also agree with Bertrand that "BASIC" doesn't sound nice. I think >>> we should keep "DOM0LESS_ENHANCED" and "DOM0LESS_XENSTORE" as suggested >>> here, but replace "DOM0LESS_ENHANCED_BASIC" with something better. Some >>> ideas: >>> >>> - DOM0LESS_ENHANCED_LIMITED >>> - DOM0LESS_ENHANCED_MINI >> Personally I do not find those more clear then BASIC >>> - DOM0LESS_ENHANCED_NO_XS >> This has the problem to be true now but would need renaming if we introduce >> a definition for an other bit. > > Internal renaming is not a problem.
Then let’s go for this. Cheers Bertrand > >>> - DOM0LESS_ENHANCED_GNT_EVTCHN >> I would vote for this one as it explicitly state what is in so the bitset >> system is even more meaningful. > > This would be fine if the flag were doing what it is supposed to do (i.e > enable grant-table and event-channel only). However, so far, it will expose > any Xen features but Xenstore. So of the features are strictly not necessary > for the grant-table/event-channel support (e.g. ballooning facilities, > runstate...). > > The name would also really confusing in the definition of ENHANCED (XENSTORE > | GNT_EVTCHN). Does this mean the domain cannot use the runstate? > > Cheers, > > -- > Julien Grall >
