From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 6261AB36F2 for ; Wed, 29 Nov 2023 09:58:22 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4BD8B24C2 for ; Wed, 29 Nov 2023 09:58:22 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 29 Nov 2023 09:58:21 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 73687422A5 for ; Wed, 29 Nov 2023 09:58:21 +0100 (CET) Date: Wed, 29 Nov 2023 09:58:20 +0100 From: Wolfgang Bumiller To: Gabriel Goller Cc: pbs-devel@lists.proxmox.com Message-ID: References: <20231127105238.99947-1-g.goller@proxmox.com> <20231127105238.99947-3-g.goller@proxmox.com> <2b073619-730b-4e39-affc-45cbc624ef7c@proxmox.com> <6e10f6cf-2d76-44f4-80f7-355bf56d3dbe@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6e10f6cf-2d76-44f4-80f7-355bf56d3dbe@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.097 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [PATCH v4 proxmox-backup 2/3] node: status: added bootmode X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2023 08:58:22 -0000 On Mon, Nov 27, 2023 at 03:02:18PM +0100, Gabriel Goller wrote: > > On 11/27/23 14:53, Wolfgang Bumiller wrote: > > On Mon, Nov 27, 2023 at 02:28:14PM +0100, Gabriel Goller wrote: > > > Thanks for the review! > > > > > > On 11/27/23 14:10, Wolfgang Bumiller wrote: > > > > On Mon, Nov 27, 2023 at 11:52:37AM +0100, Gabriel Goller wrote: > > > > > + > > > > > +#[api] > > > > > +#[derive(Serialize, Deserialize, Default)] > > > > And Clone + Copy > > > Agree > > > > > +#[serde(rename_all = "kebab-case")] > > > > > +/// The possible BootModes > > > > > +pub enum BootMode { > > > > > + /// The BootMode is EFI/UEFI > > > > > + Efi, > > > > > + /// The BootMode is Legacy BIOS > > > > > + #[default] > > > > ^ do we *need* Default on this type? And why is Bios the default? > > > Removed it. Was enabled on the `NodeStatus` struct and cascaded down, but > > > afaik we can remove it > > > on the `NodeStatus` struct as well and get rid of it. > > IMO this is one of those options where we can't have a default, so if a > > struct containing it needs to be Default, this value should be an > > Option<> in there instead. > Agree. > > But what do you think about the SecureBoot enum in the proxmox_sys crate? > Currently I have this: > > #[derive(Clone, Copy)] > pub enum SecureBoot { >     /// SecureBoot is enabled >     Enabled, >     /// SecureBoot is disabled >     Disabled, > } > impl SecureBoot { >     pub fn query() -> SecureBoot { >         lazy_static::lazy_static!( >             static ref SECURE_BOOT: Mutex> = > Mutex::new(None); >         ); > >         let mut last = SECURE_BOOT.lock().unwrap(); >         let value = last.or_else(|| { >             // Check if SecureBoot is enabled >             // Attention: this file is not seekable! >             // Spec: https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html?highlight=8be4d#globally-defined-variables >             let efivar = std::fs::File::open( > "/sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c", >             ); >             if let Ok(mut file) = efivar { >                 let mut buf = [0; 5]; >                 let Ok(_) = file.read_exact(&mut buf) else { >                         return Some(SecureBoot::Disabled); >                     }; >                 if buf[4] == 1 { >                     Some(SecureBoot::Enabled) >                 } else { >                     Some(SecureBoot::Disabled) >                 } >             } else { >                 Some(SecureBoot::Disabled) >             } >         }); >         *last = value; >         value.unwrap() >     } > } > > Although we could make the function return a bool (then we'd have a > free-standing function again), which would be simpler... (+ we convert it in > pbs to a bool anyway) > One advantage of my approach is that we are more flexible, could add another > option, rename them, etc... Sorry for the late reply. IMO both are fine. After all, if we need to change away from a bool we can just mark the function as #[deprecated] and move on from there with compiler help. I don't think we'd really lose any flexibility if in the end we turn it into a boolean on the API facing side anyway, as a change there would be an API break after all, while an internal change does not matter that much.