From nobody Thu Oct 16 20:56:01 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cngGf3mdrz6D80c for ; Thu, 16 Oct 2025 20:56:10 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cngGb6kvrz3bxs for ; Thu, 16 Oct 2025 20:56:07 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Yk0NDbFk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-57e8e67aa3eso3191839e87.1 for ; Thu, 16 Oct 2025 13:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760648165; x=1761252965; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=LOj2vygwJarwZ81sfcevPOfRutLsH/tKDTP5bR/Kazc=; b=Yk0NDbFkAoDL9kSYwa0bz668yLaIAOJgYi4hiObZB/vlxb4NYKbknjkEPyH6KofnNo laQLr00saerQrbosWimzpcGjaa3hvx5fBNE/HVBmewyYPbPBuvT+4l4Jk9kQce0aB+Gt LCCshdYNhbkkkHZCj3zi1pUkP14TYCRn+sGZS8K6zLrblB/WTYSJjuf41Of3j+PrfOLH /pCk4R8+DQXeKor0JEL4he9K4Yf46Xu2tARHJEyLvw/5UeIX0HlUgziPViObwM3e7ZeA PDcUHFMnjzwk4eIJONFxeFHCma4trloW/ejZDNCSCVUOQ7wFHrKO/1Kz1GqWYS1Stm7c DGUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760648165; x=1761252965; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LOj2vygwJarwZ81sfcevPOfRutLsH/tKDTP5bR/Kazc=; b=KGVynzxSaLjcoZ+9qsAq1VmvdN+PGnJs1RtQ8q0CwvGHqvLFqL5SV7CrylRuDJW6lF CvD8GQEZJ+Q8IwaQT5v3WR7GFmDL0ePvvOlUvCUcPYdG3sS2SYCLjz2NGk8rY82c0X9x VJXEgaqPFX1G06gqMNnNvZn0fg9agmYS7FdvKTEqP2oQTTOwUxOeQ/KUQC6gJht/nm55 XT928CDumTEfw/glk1zlYsWL2vkDtwYHhkRE/Ls8f4b57lih09c8otatDugvd/9UmyFO Zj16YfIoMeoHvLfoj0jE+qcck/kXrn1sf26uEqHN2eDzBBjMzYJLQjffhSeDHCjWMmrb tJtw== X-Gm-Message-State: AOJu0Yy39MN5j+HOfuwZo0xDqQ0+NM/F8cPTYgB+3u9Rapu4agFkFtkI 83QsZYzEZI3ARCaYKj62veGwCYTKAvx08DecDF8nt586Artt1kURGqrqYbOhyA== X-Gm-Gg: ASbGnctaEEZdef0cRyPzbQlG3TtVGexvpAtsoBpiLaIeD3wdf1xCwPUK37LuiI8DcqR 77Df7JDPzZalGrvX2INtdPVmnx0YKA/UnRmcdyFf/pP6GjHxyZOL9LYDiM9XFPDn9ozRnOQxBPg 2eWvwVyk9m95uUeYI7oYV0SoUyiIpfLybkOS2XABsG9v6vizISb04K1vXvGoOC/h7t2j7kBChoL GywltkFvRq4XNIVgs8ZtFYB7E8igfpILQXpSf4zvN4ZxTSu9AOouYGyavdrn0DrosTqWzuH17Vy AgXYaVoZWPAsxicnhnTgW5KwvMXk1+kc7yxr+6okIhFYWITztzCDxAni3/pk+g3PnKjzHDyOflZ f2dW9EYTMz7RRsXKvY6bR2MVqmYESxn/bxPoXjq5GWp1fwUcOkaacy4xpU6KLYoPhF4/A09EBt3 CiY6sSlgmEO5CVrsu8StQJeoh9HFGh9NTMzafiUjQKCupjS7BgHK73Kw== X-Google-Smtp-Source: AGHT+IGNIxHPZf36UDD4CCqH0npgUDEJfwidKIUAyj1yWFbzDPzvxNvJLzJuKNb3KokyIAl4iqnX8A== X-Received: by 2002:a05:6512:b95:b0:57f:6da2:69ec with SMTP id 2adb3069b0e04-591d8384334mr562126e87.3.1760648164341; Thu, 16 Oct 2025 13:56:04 -0700 (PDT) Received: from nuclight.lan (broadband-77-37-180-76.ip.moscow.rt.ru. [77.37.180.76]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5909a119fdbsm6073688e87.112.2025.10.16.13.56.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Oct 2025 13:56:03 -0700 (PDT) Date: Thu, 16 Oct 2025 23:56:01 +0300 From: Vadim Goncharov To: Seyed Pouria Mousavizadeh Tehrani Cc: freebsd-net@freebsd.org Subject: Re: Support for nv(9) in if_clone Message-ID: <20251016235601.2e79e2f7@nuclight.lan> In-Reply-To: <64262fc7-2c29-4749-94dc-1de2b464f270@spmzt.net> References: <64262fc7-2c29-4749-94dc-1de2b464f270@spmzt.net> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.4) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.986]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12f:from]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4cngGb6kvrz3bxs On Wed, 15 Oct 2025 11:15:03 +0330 Seyed Pouria Mousavizadeh Tehrani wrote: > Currently our ifreq interface supports nv(9) lists via ifreq_nv_req. > This allows network interface drivers to implement their configuration > using nvlists (for example: if_ovpn, if_pf*). > > There is a problem: an interface that is implemented entirely via nv(9) > cannot be configured during the cloning phase (via if_clone_create). > if_clone_create converts the ifreq struct to ifdrv and only copies > ifr_data to params, so the ifru_nv field is lost during cloning. > > I am interested in implementing a solution to this issue and am > considering two possible approaches: > > 1. Extend the ifdrv struct to include the ifreq_nv_req struct, and > verify/make sure that other implemented modules are not affected. > 2. Introduce a new ioctl, SIOCIFCREATENV, to handle the nv part > separately, which would be more complicated but potentially less > disruptive to existing modules. > > Which one do you think would be more suitable, or do you have any > alternative suggestions? I'd vote for the latter, because it also will make task easier when/if/ever the nvlist plague will be replaced by something more sane. -- WBR, @nuclight