[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 1/6] dom0: replace explict zero checks
- To: Julien Grall <julien@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
- From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 3 Aug 2023 11:58:22 -0400
- Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1691078307; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=f/NEKVxmYeOoBO1Aj3ft9iK1B2vxUt4/FmnzD0CucWk=; b=FnpYAiTM2H69prk5J7Qp+1+GH/SOlN4vvH1ZwI/xIJj0UHtJEL/Lx2xxQmZaq6Sll+aDoODiBzeVO18Y8nGQmtXnIRpxPUeXf4PEpBqHKOhTSzDxqhqQe/Qf8IKRrWDvDlxWm8cbujEkFrk+BjjrMdtlejy9nwO8sN1zLk2ZKQQ=
- Arc-seal: i=1; a=rsa-sha256; t=1691078307; cv=none; d=zohomail.com; s=zohoarc; b=jBTmvow01AHF+vVYEiaumQ4VBM7Xqg3GDhID528w12gJ/KImu2W8xCUcvcGHuM7XrRGxK0/pKVWbEuUG8FjEg+p9S7XIE/64fipd/2OLTfoeZSd6mswvoXWnHCldAo+1OS13SHjNfUpIKvmvEnWi6d4jRzcmexTZlOBty9CIzoU=
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Nathan Studer <nathan.studer@xxxxxxxxxxxxxxx>, Stewart Hildebrand <stewart@xxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 03 Aug 2023 15:58:39 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 8/3/23 09:36, Julien Grall wrote:
Hi Daniel,
Hey Julien,
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"?
Nope, you are right. All need for it drops with the static gone.
v/r,
dps
|
