From nobody Sun Oct 19 20:51:48 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 4cqW2T4TFBz6CX6T for ; Sun, 19 Oct 2025 20:52:01 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 4cqW2S6Rrdz3KLd for ; Sun, 19 Oct 2025 20:52:00 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=OlKDuSHj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::234 as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-373a56498b9so46439361fa.1 for ; Sun, 19 Oct 2025 13:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760907114; x=1761511914; 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=cMaQcr70MRy5kGWjlcbM/lr7Sge2TyaOPCVNNoG5FVI=; b=OlKDuSHjUpdPqdRClIBl+kav4Vm05jsiATdQC48hJQYtzfOKqt2hmIvrB/KtfgGKNF VfzX59eTnOR5kHVOJpju9MKA+gcEJfX4llcccLtdASaRuvJKzjfG3FWAKgi6246Td+j+ FiP/A4Txvp2+4kxax5+NtrXIe7+PAKDkx4t3PeubERBqLoPsJTlAw6hNLGQu9hCC1TIE 3dmGh7L2O2T495R7kjTZnSrxZMiS3HgvBOFh7YV2aZdP6vuyzhzjxaAH2HwQ5UJe8/tm BZy8jAF/Mos7xfhehmu7BXB/3kBVNV4EYOGQ9vXqbeoo1xFQ/Ewln1CIsplLzxrFjxbu aaUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760907114; x=1761511914; 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=cMaQcr70MRy5kGWjlcbM/lr7Sge2TyaOPCVNNoG5FVI=; b=tALK0OPAw6ZNGPnFv9IllaNkGIAKtvP1hOxgBO7LZEGwU29ity+t+OcozDT2vDcB9o NTfmpVw8CXv8Keu6k+7ldeU8uDfvzjedy4Au/qRL2NBdTePRRZ25jGle+F1iO269yDwZ KvahYPFuS8fVCmNHgyhruE/N+Pbqxx2mlCq3CHfZANpUDDffc9Gh/CPL1JwkZg8lplUW uEbdf4C6vqTP0frHcCNp/JTPTiKkAHC9+LQ0i0NhF2VOwO8o68mz0w2bLMfI+2Llugbt IgpBfF+gTwAc/fGf9IVAy2VeP9nymTzUdoXDzKhd8S9CYazvKUyH7AvU+tftwcqyjkGs 439A== X-Forwarded-Encrypted: i=1; AJvYcCXHxySmNXrJan6QlLzqL8NGCYa3x/O5iwJiQokTIr9+2STXCqUOyf55iAn9h30+JxCd+ltjOoyC/wJN8w==@freebsd.org X-Gm-Message-State: AOJu0YyeeTzivTYfXh7Mp//nBGRZl0OrlpcZvEPq8v6gw+0rfl8RKiRE ir1bqpmKFPT2OojWemBN5xN5y3KPmwEmV/Oa5egPFbxkJYc/21D4q/LtjOcfqQ== X-Gm-Gg: ASbGnct3SJRCrP94fN1Q3kqkUC2ycKRVWFmMYFhiqq5iUu9QWxHP38I7uw/b8+O4Nu6 jWHiUDPRx6AGE12Y6kkyk7kOKFWqxeJK5xs5eWQeBlloNNGyKe3OncFDqhZlV4j8T6760d3Z5Ad KY2ILDzlV46GYL1UDGpiL3uqfHRUj/Coy7BT0+Mv7QtkpNmf8ZTsFZ/i8PNsEuz6qhT3gsx/IXs R0sTn2w1zoUatsJSS8RuJJ9MYR3qPb/mtoCkaNZSlgfws1nNrP+wynJHkbhGqmRPI34mH8QO6Kl w3JkapdZSbuzYVCn8+JcMd55asRQNwGYPMIcNzfwrkkt+VIYAx2EvDLgX7/jiegeMaIhrCXJR+P 8TO06GpL2kxtznMc1n3VCMOKaiK5z7Kk3F9K1I4w2h9RxeZVQUiHPJ0ojvlRBL1QW4m13mZrWDJ RFAgdJI2g6cXDkzmVwhHdLTCtspQahBgQEOtsKdyd7mPs= X-Google-Smtp-Source: AGHT+IGfbdOVtTONZEee3iJbnSX6E9fsLgYBCMqt4nR02sMzawoELfz51BQxleooOLoS5Z1T905x+g== X-Received: by 2002:a05:651c:1608:b0:36b:ee68:b022 with SMTP id 38308e7fff4ca-37797732121mr34721091fa.4.1760907113274; Sun, 19 Oct 2025 13:51:53 -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 38308e7fff4ca-377a921d99bsm16310851fa.22.2025.10.19.13.51.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Oct 2025 13:51:52 -0700 (PDT) Date: Sun, 19 Oct 2025 23:51:48 +0300 From: Vadim Goncharov To: Kristof Provost Cc: Seyed Pouria Mousavizadeh Tehrani , freebsd-net@freebsd.org Subject: nvlist/netlink/CBOR/etc. (Was: Support for nv(9) in if_clone) Message-ID: <20251019235148.25f91a9f@nuclight.lan> In-Reply-To: <7AA688F9-8DB6-41F0-AE57-B52123BE80BB@FreeBSD.org> References: <64262fc7-2c29-4749-94dc-1de2b464f270@spmzt.net> <20251016235601.2e79e2f7@nuclight.lan> <7AA688F9-8DB6-41F0-AE57-B52123BE80BB@FreeBSD.org> 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.04 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; 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]; NEURAL_HAM_MEDIUM(-0.04)[-0.037]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::234:from]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; 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: 4cqW2S6Rrdz3KLd On Sat, 18 Oct 2025 10:37:00 +0200 Kristof Provost wrote: > On 16 Oct 2025, at 22:56, Vadim Goncharov wrote: > > On Wed, 15 Oct 2025 11:15:03 +0330 > > Seyed Pouria Mousavizadeh Tehrani wrote: > > =20 > >> Currently our ifreq interface supports nv(9) lists via ifreq_nv_req. > >> This allows network interface drivers to implement their=20 > >> configuration > >> using nvlists (for example: if_ovpn, if_pf*). > >> > >> There is a problem: an interface that is implemented entirely via=20 > >> 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? =20 > > > > I'd vote for the latter, because it also will make task easier=20 > > when/if/ever > > the nvlist plague will be replaced by something more sane. > > =20 > Absent detail this isn=E2=80=99t particularly useful feedback. >=20 > Having used nvlists in pf I=E2=80=99ve found them to be fairly useful in= =20 > defining extensible interfaces. > There are a few downsides though. The big one being horrendous=20 > performance and memory use for large requests. This likely isn=E2=80=99t = a=20 > problem for this use case. It really only bit pf for state export, which= =20 > is potentially very large. >=20 > The other downside, and the reason I=E2=80=99d be inclined to look at jus= t=20 > transitioning entirely to netlink is that dealing with them is annoying,= =20 > because you have to cope with three sizes: the size of the nvlist passed= =20 > from userspace, the size of the buffer userspace allocated and the size=20 > of the kernel=E2=80=99s reply (if applicable). It also leaves userspace t= o=20 > deal with =E2=80=98Is this buffer large enough?=E2=80=99, which isn=E2=80= =99t really=20 > something you have to think about with netlink. >=20 > As an aside, because you mention if_ovpn: I wound up using nvlists=20 > because netlink wasn=E2=80=99t available yet for FreeBSD. The Linux equiv= alent=20 > uses netlink (of course), and it would have been very nice to be able to= =20 > have the same interface on Linux and FreeBSD. That's not a detail question but rather, a values/goal one: nvlists must be considered legacy. It is understandable when they appeared in ZFS on century boundary, as there market hardly had anything usable in this area then. It = is understandable that they were still used before 2014, alternatives were you= ng then. But for nowadays, it's just an old NIH syndrome reinvented bicycle wh= eel. First of all, it is not a standard of any kind. Thus, it is not known outsi= de FreeBSD and systems having ZFS. Situation is somewhat similar to netlink: m= any tools (e.g. on GitHub) target Linux, and supporting FreeBSD requires effort, while for netlink, they can just use netlink. The same with serialization formats - any (e.g. monitoring) tool e.g. in Python could consume JSON or C= BOR with a single line of code. With nvlists, they can't - and this is not easy even if they wanted to - because unpopular format of course has no bindings for popular languages. Yes, is we want to promote FreeBSD, dynamic scripting languages must be considered as primary target. Then, it is not open =3D not being extensible. This means you can't just ad= d new data types or constructs to it even if you want - in contrast to CBOR or ev= en XML ir YAML where new types could be easily defined. Last but not least, a horrible API. Very large number of functions, so unsurprisingly vulnerabilities history, with not always consistent/intuitive naming. Consider e.g. XML: you have at least two modes, an entire accessible parsed tree (DOM) or a streaming event-driven interface (callbacks on each = new element). You can find both kind of APIs for JSON, or at least something simple and understandable in memory (e.g. cJSON); same true for the binary CBOR [RFC 8949], and our base system even have libcbor for years. In contra= st, nvlist API looks like if it was something customary above XML or JSON. The only possible upside which I see with nvlists is ability to pass file descriptor, which made into Capsicum, so nvlists, sadly, will not disappear any soon. But for all other (new) uses, it must be considered bronze age legacy and discarded in favour of something more modern, simple, extensible. Regarding netlink, this is not strict comparison - netlink is more about sending data than format of that data, like Layer 4 OSI (TCP) vs Layer 6 (JSON), so nothing prevents you from sending over netlink e.g. also nvlists or something better, like older netgraph(4)'s ng_parse (it has advantage of automatical C structs conversion) or binary CBOR or even textual JSON... the own netlink's default offered format is same stone-aged as nvlist, it just have a bunch of ready-made macros, though you will have to extend them for your data, but netlink does not insist, so you can use anything you want. --=20 WBR, @nuclight