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. Jan
