From nobody Tue Sep 30 18:11:09 2025 X-Original-To: dev-commits-src-all@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 4cbmMh4xHWz690wZ; Tue, 30 Sep 2025 18:11:12 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cbmMh34myz3KVL; Tue, 30 Sep 2025 18:11:12 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759255872; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZmfxV/6EexLIUWGuOowMzJcoAq4QFpogQTLRjzBtyRQ=; b=K8BqLYxIKpYZ2lWeXv7PuKmMgLOwuplFDcVqYAx7owQGDA31GgmfVqjb6rJwxVu80pJ+h0 zGWDXHyt3QasqDzc4rNtUj+KOYqKL1qhkYjuMaMEDRmvqmta14yHqrYScTocEc2Md5YX7k pKp52UdoM1DJMqB8csOP5gAh5v6pCZxU+lvQ7wjcyCkXaGGw8uRfEMqTXzpaPTJWWj/8Of 3OkTOjmATUO5zETphriD8YBf7ewZ0g5C8SZTHnB5354/GaPQZAX8r0GNBvCe3sMlItuIEZ kfI4Hh6J+/hJaTWBwVeAaqvajfIEguHx3T2OTTQcxMgU/DLjfPK4FqLWZqGtQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759255872; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZmfxV/6EexLIUWGuOowMzJcoAq4QFpogQTLRjzBtyRQ=; b=XFW8jkI7E9F8Ng3P+mcGLstbmBVZ7D8rbhEQPc1HnGkRvs8Bz9yl32PAG+tSJCZOczDvtT WQc27KgCcENilb3fmnrQhZWeTpkqMgKqPQS4I4ktR+jHGod8NztKq1wSqApJcaAKQn+M2w LsugToCkawd2VbiQXpXM+jdnU0c1jMTs4wlW3eE1thtMevamHIdiZJYtABGlSGs8rDjERP IqbBmR+1jd3EWs8yHu1JzeWcaoIH7y1yCqRnrsX54vZWqGtNoKREe1UCuJpCw2M9WVLCw4 3P0kxZOWCtwKkQCMloj/EY0+iq+Zx8SJkGlTly4vAd4ekbDcDj0L20Z6dCx96Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1759255872; a=rsa-sha256; cv=none; b=EqoJ8XEabGu2cCgn6lm8ze+dCsIc3uzycAHWe6eET3YN/9ldyrPVH6kCydu0exvPEOzF3g 5Ucpme3f8r6XdNp5/QOc1L8aFSFE2KiVAD86r4cpGhDs7DPuYR6Prv9CcowETvgmbtl9p0 Oww80gvqERAXXHMsLMSAwJfbkay5413g1EIY3rvODgqRFFSYsWz3QrWkHMPjF4flq6k6hW ug7ERUlDPcf9yQoVLslrCNMd7b9QhRVmsWTo9S5o2E8xtRRIOLf2lqGHN/g6VGaKW70UGn LnIdWqtIviAGUnMsJf+q1KqaURntnTo3KNa4Lw+HtaZHYmI1uBIq3WcZWV5LJA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cbmMg4zH4z10WB; Tue, 30 Sep 2025 18:11:11 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 30 Sep 2025 11:11:09 -0700 From: Gleb Smirnoff To: Kristof Provost Cc: ItzBlinkzy , Kevin Irabor , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 4e7a375804e5 - main - IfAPI: Added missing accessor for if_home_vnet Message-ID: References: <202509292116.58TLGxWx078766@gitrepo.freebsd.org> <9E63C594-08DD-43CD-BD76-3E9B9E80AA60@FreeBSD.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9E63C594-08DD-43CD-BD76-3E9B9E80AA60@FreeBSD.org> 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 in struct K> > ifnet, a function to access it shall exist? K> > K> It’s 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 was 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? -- Gleb Smirnoff