On 11.10.2021 12:45, Julien Grall wrote: > Hi Jan, > > On 28/09/2021 13:05, Jan Beulich wrote: >> On 23.09.2021 11:54, Julien Grall wrote: >>> On 23/09/2021 08:11, Penny Zheng wrote: >>>> From: Stefano Stabellini <stefano.stabell...@xilinx.com> >>>> >>>> We are passing an extra special boolean flag at domain creation to >>>> specify whether we want to the domain to be privileged (i.e. dom0) or >>>> not. Another flag will be introduced later in this series. >>>> >>>> Reserve bits 16-31 from the existing flags bitfield in struct >>>> xen_domctl_createdomain for internal Xen usage. >>> >>> I am a bit split with this approach. This feels a bit of a hack to >>> reserve bits for internal purpose in external headers. But at the same >>> time I can see how this is easier to deal with it over repurposing the >>> last argument of domain_create(). >> >> I actually have trouble seeing why that's easier. It is a common thing >> to widen a bool to "unsigned int flags" when more than one control is >> needed. > > I was suggesting this is easier for the following two reasons: > 1) All the option flags (internal and external) are in a single place. > 2) Reduce the risk to make a mistake when widening the field. In > particular in the context of backporting. Although, this looks unlikely > here. > >> Plus this makes things needlessly harder once (in the future) >> the low 16 bits are exhausted in the public interface. > > That's why I suggested this sounds like a hack. At the same time the > split between external vs internal option is a bit more a pain for the > developper. So I didn't feel pushing for one vs the other. That said, I > will not argue against if you want to push for repurposing the last > argument.
In which case - Penny, would you please change the patch accordingly? Jan
