From: Dominik Csapak <d.csapak@proxmox.com>
To: Tyst Marin <moddingfox@foxtek.us>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH] Add UI option for boot optional mapped usb device
Date: Mon, 27 Jan 2025 14:35:00 +0100 [thread overview]
Message-ID: <d04bdec6-ce86-45f5-814f-6747a2bbbe36@proxmox.com> (raw)
In-Reply-To: <a704cc43-53de-49d2-b05e-41c6aa49083b@proxmox.com>
Hi,
On 12/13/24 09:34, Dominik Csapak wrote:
> On 12/13/24 01:23, Tyst Marin wrote:
>> I'm still not really all that convinced that Map.Modify is better suited over VM.Config.HWType/
>> Mapping.Use. Mainly as it seems reasonable to expect the requirement/nonrequirement to still be a
>> hw level config to the vm and that the map should only have the role of saying which device for
>> the current node is but not anything about how it should be used by the vm. The type of user that
>> should make this change should be one with authority over if the vm should be able to boot without
>> the device. The mapping themselves seem more like someone with the authority to say what that
>> device is on a particular node. Tho that's just my opinion and i'm happy to agree to disagree on
>> that point as both places are fairly reasonable and i'm likely being a abit pedantic about it.
>
> Mhmm.. let me think about this over the weekend, but I currently still lean towards
> the map options since that is what the "higher privileged" user configures, and that person
> should be able to restrict/permit the use of the hardware.
>
Sorry for it being much longer than a weekend... with the holidays and other things i overlooked
this thread then.
Anyway since no one else commented on this in the meantime and I did not figure out a better
way, I'd say we should go with a 'mode' enum on the mapping itself, with the same reasoning:
The one creating the mapping must have the privilege to manage the device, whereas the
user adding it to the vm might not, only the priv to use it. And IMO the user with
the higher privilege in this case should be the one to decide if it should be
"reserved" or exist when the guest starts.
Hope that still aligns so that it solves your issues.
Would you be willing to provide new version of patches for that?
(if there is any question on how to start on this, just ask)
Best regards
Dominik
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-01-27 13:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-26 1:51 moddingfox via pve-devel
2024-12-04 9:40 ` Dominik Csapak
2024-12-04 21:50 ` Tyst Marin
2024-12-12 8:19 ` Dominik Csapak
2024-12-13 0:23 ` Tyst Marin
2024-12-13 8:34 ` Dominik Csapak
2025-01-27 13:35 ` Dominik Csapak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d04bdec6-ce86-45f5-814f-6747a2bbbe36@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=moddingfox@foxtek.us \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal