On 04.02.2026 11:12, Juergen Gross wrote: > On 04.02.26 11:04, Jan Beulich wrote: >> On 04.02.2026 11:01, Juergen Gross wrote: >>> On 04.02.26 10:51, Jan Beulich wrote: >>>> On 04.02.2026 10:25, Juergen Gross wrote: >>>>> On 04.02.26 10:15, Jan Beulich wrote: >>>>>> On 04.02.2026 10:00, Roger Pau Monné wrote: >>>>>>> On Wed, Feb 04, 2026 at 08:56:10AM +0100, Jan Beulich wrote: >>>>>>>> On 04.02.2026 08:49, Roger Pau Monné wrote: >>>>>>>>> Also, I would remove the tools guards, I think once a DOMID_ constant >>>>>>>>> is allocated it becomes part of the public ABI, and it cannot be >>>>>>>>> withdrawn. See for example DOMID_IDLE: it's only used internally in >>>>>>>>> the hypervisor AFAICT, yet the define is fully visible in the >>>>>>>>> headers. >>>>>>>> >>>>>>>> It was me to ask for it to be guarded like this. DOMID_IDLE (and >>>>>>>> perhaps >>>>>>>> others) not being guarded (at least for IDLE: by just __XEN__) imo was >>>>>>>> a >>>>>>>> mistake. That mistake may in fact be correctable, if we could prove >>>>>>>> that >>>>>>>> the ID cannot usefully be passed into anywhere. >>>>>>> >>>>>>> Even if it's not passed into anything, does it make sense to guard >>>>>>> them? The reserved domid values are already consumed, ie: cannot be >>>>>>> reused in any way. It just seem to me like more ifdefery churn for no >>>>>>> specific benefit. >>>>>> >>>>>> Well. From an abstract perspective, purely hypothetical at this point, I >>>>>> could see a potential need to re-number them, e.g. to simplify checking >>>>>> against groups of these special IDs. >>>>>> >>>>>> Yes, excess #ifdef-ary is an issue. Excess exposure of things also is, >>>>>> though. Finding the right balance between both can be interesting. >>>>> >>>>> I have a patch in work which would want DOMID_ANY not be guarded. I think >>>>> especially DOMID_ANY could be useful for other cases, too. >>>> >>>> Mind me asking where, outside of the toolstack, you intend to use it? >>> >>> I'd like to be able to use it for Xenstore permissions. >>> >>> Primary use case would be to allow the special watches for domain creation >>> and removal to be usable for all guests, but there might be use cases where >>> a domU wants to give node read access for everyone. >> >> Would that require exposing beyond the toolstack's boundaries? > > Yes, as this would require the user to specify DOMID_ANY as the domid in > struct xs_permissions.
Hmm, I see. I wonder though whether things like this wouldn't want a separate layer of abstraction, such that users of the library won't need to include (and hence have available) Xen's public headers. Jan
