From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Wolfgang Bumiller <w.bumiller@proxmox.com>,
Filip Schauer <f.schauer@proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 guest-common 1/1] Add foreach_passthrough_device
Date: Tue, 31 Oct 2023 10:00:44 +0100 [thread overview]
Message-ID: <95f912b4-25b8-403e-8112-50ce689cf21a@proxmox.com> (raw)
In-Reply-To: <ftprf2og5egdffjj5wb3hgipyugzdj6dixnc2hzxcdeihxkgg3@jchycj3kudvs>
On 30/10/2023 14:12, Wolfgang Bumiller wrote:
> On Tue, Oct 24, 2023 at 02:55:54PM +0200, Filip Schauer wrote:
>> +
>> + $func->($key, "dev/bus/usb/$bus_id/$device_id", @param);
>
> So this will do... something :-)
> But unfortunately it won't deal with the *interesting* bits.
>
> So while I do like the idea of having such mappings, for it to make
> sense we'd also need to figure out the device specific nodes.
> Eg. for input devices we'd want to include `/dev/input/eventXY`, for eg.
> FIDO keys we'd want `/dev/hidraw*` devices.
>
> I'm not sure how much work we should put into this in the initial
> implementation, the question is mainly whether we want to do it like
> *this* in the first place and how much we plan to support.
Hmm, yeah, let's leave the USB mappings out for now, not really winning
much here.
>
> Or maybe it would make more sense to have specific entries for hidraw,
> event devices, block devices, ... instead?
> I'm not sure.
A device (node) mapping with a sub-type like block ("disk") devices might
be indeed better then, as that could be re-used for VMs too, e.g., for
passing through a /dev/sda (well, more likely via /dev/disk/by-id/...)
device through. IIUC, that would be also more in line with Dominik's
feedback.
In any way, let's get raw pass-through right first, adding in mappings
should be doable then, we added them only much later for VMs too, so
I'd think one would have to actively try to really make that hard to
do in the future here.
prev parent reply other threads:[~2023-10-31 9:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 12:55 [pve-devel] [PATCH many v2] Add container device passthrough Filip Schauer
2023-10-24 12:55 ` [pve-devel] [PATCH v2 container 1/1] Add " Filip Schauer
2023-10-30 13:34 ` Wolfgang Bumiller
2023-11-02 14:28 ` Filip Schauer
2023-11-03 8:14 ` Wolfgang Bumiller
2023-11-07 13:49 ` Filip Schauer
2023-10-24 12:55 ` [pve-devel] [PATCH v2 guest-common 1/1] Add foreach_passthrough_device Filip Schauer
2023-10-30 13:12 ` Wolfgang Bumiller
2023-10-31 9:00 ` Thomas Lamprecht [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=95f912b4-25b8-403e-8112-50ce689cf21a@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=f.schauer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=w.bumiller@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal