[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/4] dt-overlay: Remove ASSERT_UNREACHABLE from add_nodes()
- To: Julien Grall <julien@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Michal Orzel <michal.orzel@xxxxxxx>
- Date: Mon, 23 Sep 2024 12:44:25 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=actwuHEvnZspDQ/Z1PnYpS5hk51dpyRAjzyCpaZwyPU=; b=PuKYu85lUYc2HbWS7BJoaUxxh93CMvCdr3O1K0Z9adPWUpAS2FZtgVJHEk1GUSwH5L0fA4Scy1uCqHjWRl/xtjdC3sMt1I7sJIjdwsXffDhajrUNK4euficR8ERmkBPzSeoWtEJuricRelBcZGoE94sypQlq7c6btkkMtBFTFxNNfq5PnswXngn/JfcHJQS65CS1BGvp/9Fs6zjVp4lkd/eZrTZYGC8vbZsxQS8GWH+l4jCGcuPkqCg6QO38FGNfK3iv9IYJxPpvnuHMP5HyQZuxsquThYIkWLK15b2pMcaDK02w1dW5KMlN7pbgOvLMrhREEvWmeKx9x3O0MD4HRg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JClQsORBoPyVoyjymuG1f1ivl1eoByoNYNIjdkaOGz1zYEwEVxFemp6UbYi0IpEK5fgv3MXiu8dSEOvdfWN3B2VgfnfvL0+7UbYB7BmK1Scb0/WCZOKUm2wr6c2/8AmMc1RyFS6OHOI8qkoAkZeohKjoFUEfGyjZrRi9LpGJOGa1F0KSPMy2R6cMr92gByZPVEL5w90nOaCif7mmTCKZhxKRAQnUG2BqpNqXlLTaXF6XkpccBQESrHN8ofcABOWTt9RwMIRme/gXuFTyvRzAPmFBJhO4AjXerOSb9vNb+mV0ATwxLlWWiw+cCUG8hNeK1i7Vh1Yc7nTzatWdZ2ZojQ==
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>
- Delivery-date: Mon, 23 Sep 2024 10:44:41 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hi Julien,
On 20/09/2024 10:35, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 19/09/2024 12:42, Michal Orzel wrote:
>> The assumption stated in the comment that the code will never get there
>> is incorrect. It's enough for the target-path to be incorrect (i.e. user
>> error), which will lead to an incorrect overall node path and we will end
>> up in this "unreachable" place causing a failure in debug builds.
>
> Looking at the caller, nodes_full_path contain path that was computed
> from the overlay. So I would have assumed the path would be part of the
> new DT. What did I miss?
nodes_full_path contains paths to nodes by combining the name of the node with
the target-path string.
It's generated in overlay_get_nodes_info(). It's a simple <target-path> + '/' +
<node-path> + '\0'. It does
not have any dt logic as for paths. On the other hand libfdt contains advanced
logic and can tweak the node
path if needed. So for example if the target-path is "////" and node path is
"foo@0", libfdt full path will be "/foo@0"
(notice how it got rid of excessive slashes) but our nodes_full_path[foo] will
be "////foo@0". The only place which can
spot this difference is our check in add_nodes().
~Michal
|
