Date: Thu, 16 Oct 2025 23:56:01 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: Seyed Pouria Mousavizadeh Tehrani <info@spmzt.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Oct 2025 11:15:03 +0330 Seyed Pouria Mousavizadeh Tehrani <info@spmzt.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20251016235601.2e79e2f7>