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? Note that unlike IDLE and perhaps a few others, ... > Look e.g. at XEN_ARGO_DOMID_ANY. Even if I don't think we can switch it > to DOMID_ANY, it shows that the concept as such is not restricted to Xen > internal use cases. ... I don't mean ANY to be constrained to just the hypervisor. That more strict guarding came up only because of Roger mentioning IDLE. Jan
