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. 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. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
