From nobody Wed Oct 01 08:27:05 2025 X-Original-To: dev-commits-src-main@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 4cc7MY1Dv4z698ZS for ; Wed, 01 Oct 2025 08:27:21 +0000 (UTC) (envelope-from kevin.irabor04@gmail.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 4cc7MX6HtYz43gc for ; Wed, 01 Oct 2025 08:27:20 +0000 (UTC) (envelope-from kevin.irabor04@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-3352018e050so6332807a91.2 for ; Wed, 01 Oct 2025 01:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759307239; x=1759912039; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Bw/t/YkIZEVDad0Hjx/eOkSBU4Bg/A4YLM0uTIa1HyI=; b=KrnE8mImxX1eyBhTwJCZgZgT4dg1XB6W7KPBPJJz8EZmc4eDeQQxzH9vlcfSXPQ5Ht xyBuSNbxA5l/Atyc6C0tgy0vt9/d5Jtph8omwsDV+oepDaqH+x3JpY+p9rI9vZtRdvS6 nVnc0Zm2enud1jrstQMkzDr0Rh3ee225iZlHbLGHcMZ6cmgcVCfugiXow53Pi/NyzrcY DMxZJFfOqEcnf2XVEhcHbolbBlk3/qcgeKfDUIjTAKtUOrHbvv61ZRmcRXi2M08mF2BT 1g3IF0epy3C3DmeJ/AjTqCh0AWzoeWJzRSl4WAVgncDIX4qnIQ+TT3LAyXYYy+LowrXG 3vhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759307239; x=1759912039; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bw/t/YkIZEVDad0Hjx/eOkSBU4Bg/A4YLM0uTIa1HyI=; b=d2QPUWhcO9HDLgkW/3e48GasdfDJ23kUcPm3CVL0deB4FEkNyMe9BgxxlWrX88INRT OvB8TktDnsxvUGrGaGOKeenZ0Kdfr4IPrW8AIImB2v+xGRKXjuZPr/pKt2ACS5va4IcM hBCkgLwL8WHpIPrL9UzxnEODTqqOa+b3qgB7a194t6I6gCG2/HuUQiQPMxpJMhFJ7zJB 6Fi0wvHvU13+JlbKnhQDGVedAQ8LEAAv1ozd5UrTl9HXyKse4dtZKzdyEE7zJVYSsdGH m+lNk10HcrnaV6sAjQBA/WubhS7s4B9uXL+naF9S6OAcHFgVV3gCIFFE5m5VN4TfvdLN vvkw== X-Forwarded-Encrypted: i=1; AJvYcCXq/7+jLAgp19nCY5ztJm5eA18B8TOggiC13P79Yv1pMGMyO9xCHKlm3RVzjceDX0wcQ2AVZVa4Vk/nrPQMiIVDohF9EA==@freebsd.org X-Gm-Message-State: AOJu0YwmGFdhpsiOtBDU7VJxGTIMEIE2nNDbaALuX9UXScWCTzQCGdNW hugCO0JmXldwQF1DTWiZUl1hoVoFeSylbcGj1PiADe9ry6XcB7GxIY2EEgh9EXNZ5vZaAxZu8ng smZFOdI6o9WrlwwZLxsjCfwDI9M+B8cM= X-Gm-Gg: ASbGncuFQVjDDWCBjBB+L/ubcIyuWdYogOGkkQbRQ8ZKDc4oJLz/N1TuD20JSEWfjcm 8wtJP5/AwnHKoUztuNfnbYd8opV3T0sj8FJOQDYU6yUdwmrvtlXL/xvMrhpiPmykYSezOowxe1a /huJ6jmegDseKyqAim6BOHtGkGP+l7mhafbpkSvK/rc+lND/lk10cM2guTuFNYFtvIhqXTWY7Bf C49XP1vgGV8KlL3+o4LUybjBNOJfh19 X-Google-Smtp-Source: AGHT+IGBrjnmrx8lyvquOSZbENC7qc3wPHZGo6aXldWpWxMC7kA5AQLhpaAcLfQv2pnBo9zFONIiNIoQLn/ET5JHN3Q= X-Received: by 2002:a17:90b:3911:b0:32e:4924:690f with SMTP id 98e67ed59e1d1-339a6e63b8fmr2875389a91.6.1759307238515; Wed, 01 Oct 2025 01:27:18 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <202509292116.58TLGxWx078766@gitrepo.freebsd.org> <9E63C594-08DD-43CD-BD76-3E9B9E80AA60@FreeBSD.org> In-Reply-To: From: Kevin Irabor Date: Wed, 1 Oct 2025 09:27:05 +0100 X-Gm-Features: AS18NWANaIRQyhoiXwZu8Em4aWy0FVwkJYfp74PzVR002IxE4NOcyIrVixDcDls Message-ID: Subject: Re: git: 4e7a375804e5 - main - IfAPI: Added missing accessor for if_home_vnet To: Kristof Provost Cc: Gleb Smirnoff , ItzBlinkzy , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="00000000000000a82c064014a3b0" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cc7MX6HtYz43gc --00000000000000a82c064014a3b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Both emails are mine - one I use as my GitHub email and the one I signed off with is my personal email. Sorry for the confusion there. To answer your questions: I was browsing the ifnet code and saw the earlier IfAPI commits that were made. I assumed the pattern was to provide accessors for every field in struct ifnet, and to maintain consistency I added this one since it was missing. I'm not aware of any drivers that need if_home_vnet and if_vmove Regards, Kevin. On Wed, Oct 1, 2025 at 8:49=E2=80=AFAM Kristof Provost wro= te: > On 30 Sep 2025, at 20:11, Gleb Smirnoff wrote: > > On Tue, Sep 30, 2025 at 07:51:05PM +0200, Kristof Provost wrote: > > K> > The actual question is whether there is a driver that really needs > to access > > K> > this field or was this added by the logic that if a field exists i= n > struct > > K> > ifnet, a function to access it shall exist? > > K> > > > K> It=E2=80=99s hard to predict what fields will be relevant for out-of= -tree > consumers, but it seems reasonable to allow access to this one given we > already allow the current vnet to be accessed too. > > > > As we discussed earlier through the last decade, the ifnet is poorly > designed > > and we need a new API. But as that was a heavy weight to lift, that wa= s > never > > finished. Juniper came with a plan to provide accessors. They would > not make > > API any better or prettier, but would basically provide binary > compatibility > > for a case when struct ifnet grows or is rearranged but all existing > fields > > remain! We agreed that this is an interim step towards a better API in = a > > future. The Juniper's API shall provide access to minimal set of ifnet > fields > > that current drivers use. It should not encourage use of fields that > belong to > > the stack, not to the drivers. So, the question is what is the driver > that > > needs if_home_vnet? Who is maintaining it and what are they going to do > if I > > remove if_home_vnet together with if_vmove? > > > Good questions. I hope Kevin can tell us what his use case for this is, > because it=E2=80=99s always easier to think about these things with speci= fic > problems in mind. > > =E2=80=94 > Kristof > --00000000000000a82c064014a3b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello= ,
Both emails are mine - one I use as my GitHu= b email and the one I signed off with is my personal email. Sorry for the c= onfusion there.
To answe= r your questions:
I was browsing the ifnet code and saw the earlier IfAPI commits that were = made. I assumed the pattern was to provide accessors for every field in str= uct ifnet, and to maintain consistency I added this one since it was missin= g.
I'm= not aware of any drivers that need if_home_vnet and if_vmove
<= div>Regards,
Kevin.


On Wed, Oct 1, 2025 at 8:49=E2=80=AFAM Kristof Provost &l= t;kp@freebsd.org> wrote:
=
On 30 Sep 2025, at 20:11,= Gleb Smirnoff wrote:
> On Tue, Sep 30, 2025 at 07:51:05PM +0200, Kristof Provost wrote:
> K> > The actual question is whether there is a driver that reall= y needs to access
> K> > this field or was this added by the logic that if a field e= xists in struct
> K> > ifnet, a function to access it shall exist?
> K> >
> K> It=E2=80=99s hard to predict what fields will be relevant for ou= t-of-tree consumers, but it seems reasonable to allow access to this one gi= ven we already allow the current vnet to be accessed too.
>
> As we discussed earlier through the last decade, the ifnet is poorly d= esigned
> and we need a new API.=C2=A0 But as that was a heavy weight to lift, t= hat was never
> finished.=C2=A0 Juniper came with a plan to provide accessors.=C2=A0 T= hey would not make
> API any better or prettier, but would basically provide binary compati= bility
> for a case when struct ifnet grows or is rearranged but all existing f= ields
> remain! We agreed that this is an interim step towards a better API in= a
> future.=C2=A0 The Juniper's API shall provide access to minimal se= t of ifnet fields
> that current drivers use. It should not encourage use of fields that b= elong to
> the stack, not to the drivers. So, the question is what is the driver = that
> needs if_home_vnet? Who is maintaining it and what are they going to d= o if I
> remove if_home_vnet together with if_vmove?
>
Good questions. I hope Kevin can tell us what his use case for this is, bec= ause it=E2=80=99s always easier to think about these things with specific p= roblems in mind.

=E2=80=94
Kristof
--00000000000000a82c064014a3b0--