From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 9FE6E1FF139 for ; Tue, 10 Feb 2026 14:21:27 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 215BC1964; Tue, 10 Feb 2026 14:22:10 +0100 (CET) Message-ID: <43f313d3-3907-4b0e-acf8-32ef3f8db0b1@proxmox.com> Date: Tue, 10 Feb 2026 14:22:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH qemu-server v3 2/3] tests: improve multiarch build support by allowing re-init of cpu models To: Dominik Csapak , pve-devel@lists.proxmox.com References: <20260205141959.3615131-1-d.csapak@proxmox.com> <20260205141959.3615131-3-d.csapak@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260205141959.3615131-3-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770729641307 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.015 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 3T7YFEKQWFGY2V2B6HCMTSI4OF3RH2HA X-Message-ID-Hash: 3T7YFEKQWFGY2V2B6HCMTSI4OF3RH2HA X-MailFrom: f.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 05.02.26 um 3:18 PM schrieb Dominik Csapak: > instead of simply saving 'host_arch','all_cpu_models' and > 'cpu_models_by_arch' in the global package namespace, after initializing > directly in the module, use an initialization function and a getter to > generate this. > > This has two advantages: > * Only the first use actually fills the package wide variable > (currently the $cpu_fmt uses this on module load) > * We can call the initialization manually in the tests where we need it > > Signed-off-by: Dominik Csapak Reviewed-by: Fiona Ebner but one comment below > +# returns the cpu models for the given architecture, or if $arch is not given, a > +# map from available architectures to models > +sub get_cpu_models_by_arch { > + my ($arch) = @_; > + initialize_cpu_models() if !defined($cpu_models_by_arch); > + return $cpu_models_by_arch->{$arch} if defined($arch); > + return $cpu_models_by_arch; > +} I don't like having an overloaded return type here (depending on whether $arch is set or not, the returned hash has different structure). All callers pass the arch explicitly, so should we just require the argument to be set and avoid returning the full hash?