Re: [pbs-devel] [PATCH v4 proxmox-backup 2/3] node: status: added bootmode

[Gabriel Goller <g.goller@proxmox.com>]

Submitted a new version!

On 11/29/23 09:58, Wolfgang Bumiller wrote:
> 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<Option<SecureBoot>> =
>> 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.