Re: [RFC 1/6] dom0: replace explict zero checks

[Julien Grall <julien@xxxxxxx>]

Hi Daniel,

On 03/08/2023 14:33, Daniel P. Smith wrote:
> On 8/2/23 03:46, Jan Beulich wrote:
> > On 01.08.2023 22:20, Daniel P. Smith wrote:
> > > A legacy concept is that the initial domain will have a domain id of 
> > > zero. As a
> > > result there are places where a check that a domain is the inital 
> > > domain is
> > > determined by an explicit check that the domid is zero.
> > It might help if you at least outlined here why/how this is going to
> > change.
> Okay, I will try expanding on this further.
>
> > > --- a/xen/include/xen/sched.h
> > > +++ b/xen/include/xen/sched.h
> > > @@ -1058,6 +1058,13 @@ void scheduler_disable(void);
> > >   void watchdog_domain_init(struct domain *d);
> > >   void watchdog_domain_destroy(struct domain *d);
> > > +static always_inline bool is_initial_domain(const struct domain *d)
> > > +{
> > > +    static int init_domain_id = 0;
> > This may then also help with the question on why you use a static
> > variable here. (In any event the type of this variable wants to
> > be correct; plain int isn't appropriate ...
> Ah, so this is a dated patch that I brought because of the abstraction 
> it made. The intent in the original series for making it static was in 
> preparation to handle the shim case where init_domid() would have return 
> a non-zero value.
> So the static can be dropped and changed to domid_t.
Looking at one of the follow-up patch, I see:

 static always_inline bool is_initial_domain(const struct domain *d)
 {
-    static int init_domain_id = 0;
-
-    return d->domain_id == init_domain_id;
+    return d->role & ROLE_UNBOUNDED_DOMAIN;
 }

So is there any point to have the local variable? IOW, can't this simply 
be "d->domain_id == 0"?
Cheers,

--
Julien Grall