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 4A96B1FF145 for ; Thu, 05 Feb 2026 09:27:25 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E0D9F8AE0; Thu, 5 Feb 2026 09:27:57 +0100 (CET) Message-ID: <7573bcbe-af00-41ed-9204-fb4db63ab634@proxmox.com> Date: Thu, 5 Feb 2026 09:27:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH qemu-server v2 1/2] tests: improve multiarch build support To: Dominik Csapak , pve-devel@lists.proxmox.com References: <20260204100425.1303295-1-d.csapak@proxmox.com> <88e10fbe-3231-40da-8ea2-d95fc1576715@proxmox.com> <7fd01f54-4148-4cb4-8d22-bf68d2e9855e@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <7fd01f54-4148-4cb4-8d22-bf68d2e9855e@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770279966410 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.020 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: C4ZYTWQ2KUFHTZWYEOLBNZTJ7PQ2XGN7 X-Message-ID-Hash: C4ZYTWQ2KUFHTZWYEOLBNZTJ7PQ2XGN7 X-MailFrom: t.lamprecht@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 08:50 schrieb Dominik Csapak: > On 2/4/26 4:45 PM, Thomas Lamprecht wrote: >> Am 04.02.26 um 11:04 schrieb Dominik Csapak: > [snip] >>> +initialize_cpu_models(); >> >> this now still always does this on module load, would be nicer to actually >> only pay for that if needed by adding getter methods for each variable, like >> >> sub get_all_cpu_models { >> initialize_cpu_models() if !defined($all_cpu_models); >> return $all_cpu_models; >> } >> >> Same with a get_cpu_models_by_arch getter. > > not sure if that gains us anything, since we need the 'all_cpu_models' hash statically for the 'reported-model' enum of $cpu_fmt, so even if i put it in a getter, it would still get initialized on module load... It still nicer to have, especially if this would be decoupled in the future. Else we can stop clean separation and just always initialize everything globally everywhere, to exaggerate for the points sake. > also not sure if having two seperate getters make sense, since > the 'all_cpu_models' one depends on the cpu_models_by_arch one. I'm not sure if I see what a data dependency has to do with not having a cleaner getter interface to better encapsulate that local variable off and hedge against someone just making it an "our" shared variable in the future. A shared initialization code path doesn't IMO mean that one has to couple using the result of that together. > So in that case we'd have to initialize both anyway (again, on module load). Yes, but that's just a detail of the current implementation, not–to over play the point–making it ugly because it doesn't matter *now* for the *current* use case. Even there it's nicer to not have a module wide variable used directly, as for all but small scripts that seldomly makes code more readable. > so this would make code a bit more complicated, but I don't really see the gain here. How is having a getter and making the initialization a local "my sub" complicated? I basically provided the getter code for one variable already, the other one is basically just a copy of that, and adaption to using these getter's should be straight forward.. btw., now that I'm thinking more of this, might be even nicer to clean this up even slightly more and produce a minimal CPUModels perl module on build time, as the info won't ever change during run time, and for testing it should make it even easier to override things there. And then these could be constants, where I would not care that much anymore about directly accessing them, but won't help testing and using constants over getters is IMO not really cleaner for non-scalar values most of the time (as always there certainly are exceptions).