From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 99E3545C26; Thu, 31 Oct 2024 21:16:46 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8BA5A4028A; Thu, 31 Oct 2024 21:16:46 +0100 (CET) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by mails.dpdk.org (Postfix) with ESMTP id D71CD40264 for ; Thu, 31 Oct 2024 21:16:44 +0100 (CET) Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2fb5014de17so533531fa.2 for ; Thu, 31 Oct 2024 13:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1730405804; x=1731010604; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EclYH1g398qIhyl+97bOsXJw8N4Hxau+UFwOmU5sxN8=; b=U4WjWSpEL8N0SmvJHVjUoopjrMGj8ZI3cswYR+LvIBm5irvgGQk59AMDQCIzimtlXd cFMim7GYVHp6b8ke7syGHnTI2lF13voJOx3Lw7YEcp4OAcKznp+KC1T98qd2T7TFlcSN 9zdCOTQkhWgbD/zzU8pvD+lWKn8Fib7Klf/wU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730405804; x=1731010604; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EclYH1g398qIhyl+97bOsXJw8N4Hxau+UFwOmU5sxN8=; b=Rf1wcXtfY9rJslXk+5E3xhN+5laJnlzdN55xuTWkQLI0IWHkYN8+z4tcEtFCn4rTQr JuFZbsStlOmNr4h3gBn7cX8/+4A08h7HnaQwj1rmP7llVTeMy6AJvejFEmv7I7fTKneE laIsKoV2wgKgYZdbk4eE7Pw4X4+++/0dQZuAmaMou7t5t/nfL+wSxNgnOoJiAy1PB99o qw97bmbekYtk9FR39DdhN4WUKT3tHmeD9jcbNuhvV1Zj1dW5GUXD1Sqcmtzfj2lw73Ni hw8nR+emKbF0fm1BKYu3y8FUGMO4QGSq9YqW9auKqZ96iVU3FxBBEz1Adi2A+26CAvvl ikAQ== X-Gm-Message-State: AOJu0Yyc1Dz2+TUkGgOkPy6/wPBGGdv9jmjj4aw2pOuAMD+DIaYw9W4V kDLHm5ASdjT0kGUFI0AMRmEMJY5TJkm2uIHiBxv4HT2kWK/H4s0mriqStJOcu1QfZe+gRpfkPsZ N9BQw/M2j/tWGaHd4WVWogIHQsvkwSIB5fCfwrA== X-Google-Smtp-Source: AGHT+IE3vePXzxAEtuOASUTr0aALZoa3JTPw4xZf+4Ae8hj2FXIiYTyQsb35Qboth/ZII/MCp1jjRLOtefHzwwQcpUk= X-Received: by 2002:a2e:be85:0:b0:2fb:56c1:c4 with SMTP id 38308e7fff4ca-2fcbdf6376dmr30632141fa.3.1730405804156; Thu, 31 Oct 2024 13:16:44 -0700 (PDT) MIME-Version: 1.0 References: <20240822163941.1390326-1-luca.vizzarro@arm.com> <20241028174949.3283701-1-luca.vizzarro@arm.com> <20241028174949.3283701-4-luca.vizzarro@arm.com> In-Reply-To: <20241028174949.3283701-4-luca.vizzarro@arm.com> From: Nicholas Pratte Date: Thu, 31 Oct 2024 16:16:31 -0400 Message-ID: Subject: Re: [PATCH v4 3/8] dts: refactor build and node info classes To: Luca Vizzarro Cc: dev@dpdk.org, Paul Szczepanek , Patrick Robb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org It took me a second to appreciate what the goal of separating this is, but it makes complete sense to me now. This was an oversight on my end as well when I was working on the config changes in once of the patches I was assigned. Interestingly enough, I ran into a similar problem with circular dependencies a long time ago when I was attempting to do some 'arch' discovery changes, which I still intend to implement. I think putting the node config in the os_session component makes sense from a readability standpoint as well. On Mon, Oct 28, 2024 at 1:51=E2=80=AFPM Luca Vizzarro wrote: > > The DPDKBuildInfo and NodeInfo classes, representing information > gathered in runtime, were erroneously placed in the configuration > package. This moves them in more appropriate modules. > > NodeInfo, specifically, ia moved to os_session instead of node mostly Small typo here, change 'ia' to 'is'. > as a consequence of circular dependencies. And given os_session is the > top-most module to reference it, it appears to be the most suitable > place outside of node. As I said, this makes sense to me, but I wonder if it might make sense to change 'NodeInfo' to 'OSSessionInfo' or something like that. I'd imagine that if any attributes were to be tacked on in the future they would probably be os related, but maybe there would be system information, and in this case "OSSessionInfo" might be a good middle ground. There are existing changes that I've done where arch is discovered during runtime, and this could probably be placed in this 'NodeInfo' class as well when I get around to revising it. My only concern is whether or not having "NodeConfiguration" and "NodeInfo" classes floating around might make the framework more confusing to read.