all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Filip Schauer <f.schauer@proxmox.com>
To: Wolfgang Bumiller <w.bumiller@proxmox.com>,
	Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v4 container 1/1] Add device passthrough
Date: Thu, 16 Nov 2023 12:52:31 +0100	[thread overview]
Message-ID: <97c2f797-2a8b-431b-84d2-47678c72fd5b@proxmox.com> (raw)
In-Reply-To: <ijtfmcmi3sb37jtknsrp3s4c3raosw67k7zdufu5pfxtmb3jiv@ayt62obbll6f>

Patch v5 available

https://lists.proxmox.com/pipermail/pve-devel/2023-November/060285.html

On 16/11/2023 09:32, Wolfgang Bumiller wrote:
> On Wed, Nov 15, 2023 at 03:14:50PM +0100, Thomas Lamprecht wrote:
>> concept wise this looks pretty much OK, but a few (mostly code-style) comments in line
>>
>> Am 13/11/2023 um 11:30 schrieb Filip Schauer:
>>> diff --git a/src/PVE/LXC/Config.pm b/src/PVE/LXC/Config.pm
>>> index 56e1f10..9f325f2 100644
>>> --- a/src/PVE/LXC/Config.pm
>>> +++ b/src/PVE/LXC/Config.pm
>>> @@ -29,6 +29,7 @@ mkdir $lockdir;
>>>   mkdir "/etc/pve/nodes/$nodename/lxc";
>>>   my $MAX_MOUNT_POINTS = 256;
>>>   my $MAX_UNUSED_DISKS = $MAX_MOUNT_POINTS;
>>> +my $MAX_DEVICES = 256;
>>>   
>>>   # BEGIN implemented abstract methods from PVE::AbstractConfig
>>>   
>>> @@ -908,6 +909,71 @@ for (my $i = 0; $i < $MAX_UNUSED_DISKS; $i++) {
>>>       }
>>>   }
>>>   
>>> +PVE::JSONSchema::register_format('pve-lxc-dev-string', \&verify_lxc_dev_string);
>>> +sub verify_lxc_dev_string {
>>> +    my ($dev, $noerr) = @_;
>>> +
>>> +    if (
>>> +	$dev =~ m@/\.\.?/@ ||
>>> +	$dev =~ m@/\.\.?$@ ||
>> could be a single regex:
>>
>> $dev =~ @/\.\.?(?:/|$)@
>>
>> but no hard feelings, all variant are not easily readable and need close
>> checking anyway (iow. like most regexes)
>>
>>> +	$dev !~ m!^/dev/!
>>> +    ) {
>>> +	return undef if $noerr;
>>> +	die "$dev is not a valid device path\n";
>>> +    }
>>> +
>>> +    return $dev;
>>> +}
>>> +
>>> +PVE::JSONSchema::register_format('file-access-mode-string', \&verify_file_access_mode);
>>> +sub verify_file_access_mode {
>>> +    my ($mode, $noerr) = @_;
>>> +
>>> +    if ($mode !~ /^[0-7]*$/) {
>> this would allow an empty mode though? Also, not sure if we want to allow
>> partial modes like 77 ?
> Yeah, an empty mode should not be allowed. Not sure what you mean by
> partial though, other than the missing leading zero.
>
> For octal we should definitely enforce the leading zero.
>
>>> +	return undef if $noerr;
>>> +	die "$mode is not a valid file access mode\n";
>>> +    }
>>> +
>>> +    return $mode;
>>> +}
>>> +
>>> +my $dev_desc = {
>>> +    path => {
>>> +	optional => 1,
>>> +	type => 'string',
>>> +	default_key => 1,
>>> +	format => 'pve-lxc-dev-string',
>>> +	format_description => 'Path',
>>> +	description => 'Device to pass through to the container',
>>> +	verbose_description => 'Path to the device to pass through to the container',
>>> +    },
>>> +    mode => {
>>> +	optional => 1,
>>> +	type => 'integer',
>>> +	format => 'file-access-mode-string',
> ... this should be `type => 'string'` (integer just doesn't enforce a
> format),
> the `format` should be dropped (including the registered sub above), and
> instead use 'pattern' as:
>
>      pattern => '0[0-7]*',
>
> JSONSchema anchors the pattern, so no need to include '^' and '$',
> although I also wouldn't mind using
>
>      pattern => qr/^0[0-7]*$/,
>
>>> +	format_description => 'Octal access mode',
>>> +	description => 'Access mode to be set on the device node',
>>> +    },
>>> +    uid => {
>>> +	optional => 1,
>>> +	type => 'integer',
>>> +	description => 'User ID to be assigned to the device node',
>>> +    },
>>> +    gid => {
>>> +	optional => 1,
>>> +	type => 'integer',
>>> +	description => 'Group ID to be assigned to the device node',
> Add `minimum => 0`, to both uid and gid.




      reply	other threads:[~2023-11-16 11:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-13 10:30 [pve-devel] [PATCH v4 many] Add container " Filip Schauer
2023-11-13 10:30 ` [pve-devel] [PATCH v4 common 1/2] tools: Add mknod syscall Filip Schauer
2023-11-13 14:12   ` [pve-devel] applied: " Thomas Lamprecht
2023-11-13 10:30 ` [pve-devel] [PATCH v4 common 2/2] tools: Add mount flag constants Filip Schauer
2023-11-13 14:14   ` [pve-devel] applied: " Thomas Lamprecht
2023-11-14 12:57     ` Wolfgang Bumiller
2023-11-13 10:30 ` [pve-devel] [PATCH v4 container 1/1] Add device passthrough Filip Schauer
2023-11-15 14:14   ` Thomas Lamprecht
2023-11-16  8:32     ` Wolfgang Bumiller
2023-11-16 11:52       ` Filip Schauer [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=97c2f797-2a8b-431b-84d2-47678c72fd5b@proxmox.com \
    --to=f.schauer@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@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