On Wed, 15 Oct 2025 11:15:03 +0330 Seyed Pouria Mousavizadeh Tehrani <[email protected]> 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
