Re: [pbs-devel] [PATCH v2 proxmox{-backup, } 0/3] Add boot_mode, improve kernel version

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

On 11/27/23 09:41, Gabriel Goller wrote:

> Thanks for the review!
>
> On 11/24/23 15:45, Thomas Lamprecht wrote:
>> Thanks for patch and review to both, but IMO this is still differing 
>> to much
>> from Proxmox VE's endpoint without any real justification?
>>
>> There the "boot-info" object with the required key "mode" and the 
>> optional
>> "secureboot" entry, that explicitly de-couples the general mode from 
>> some
>> mode-specific detail.
>>
>> The fitting rust struct (at least in sys) would be
>>
>> pub enum BootModeInformation {
>>      /// The BootMode is EFI/UEFI, the boolean specifies if secure 
>> boot is enabled
>>      Efi(bool),
>>      /// The BootMode is Legacy BIOS
>>      Bios,
>> }
>>
>>
>> or if one wants to be overly specific then something like:
>>
>> pub enum SecureBoot {
>>      Enabled,
>>      Disabled,
>> }
>>
>>
>> pub enum BootModeInformation {
>>      /// The BootMode is EFI/UEFI
>>      Efi(SecureBoot),
>>      /// The BootMode is Legacy BIOS
>>      Bios,
>> }
>>
>> (but could be overkill)
>>
>> It's not a hard must to keep this the same for pve-manager and pbs, 
>> but IMO
>> one should have very good reason for changing the format for relaying 
>> the
>> exact same information between two products, such inconsistencies 
>> make it
>> harder to interact with our API for any users, or external devs, and 
>> also
>> won't make it easier to reuse widgets for the (current or future) UIs..
> Ok, I will implement this in v2.
> I think I'll choose the second one with the specific enum for 
> `SecureBoot`. Will
> be more clear what is means (without looking at comments) + won't use 
> more memory
> than the bool version.
>
On a second note, I don't like this.
We don't support enum variants (fields) with the `api` macro, so I would 
have to create
a struct containing `mode` and `secureboot`. That again implies that 
bios + secureboot is
possible, which is not.
But I get your argument about consistency between products, so if we'd 
go that
way, I'd send another patch with the requested changes...