From owner-freebsd-arch@FreeBSD.ORG Fri Apr 3 11:03:50 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20A8B517; Fri, 3 Apr 2015 11:03:50 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C8A78EC; Fri, 3 Apr 2015 11:03:48 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t33B3jCu072377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 14:03:45 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t33B3jHa072376; Fri, 3 Apr 2015 14:03:45 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 3 Apr 2015 14:03:45 +0300 From: Gleb Smirnoff To: Anuranjan Shukla Subject: Re: opaque ifnet progress Message-ID: <20150403110345.GM64665@glebius.int.ru> References: <20150319154309.GT64665@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "arch@FreeBSD.org" , "net@FreeBSD.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 11:03:50 -0000 Anuranjan, On Fri, Apr 03, 2015 at 01:42:49AM +0000, Anuranjan Shukla wrote: A> Hello Gleb, A> Thanks for sharing the details. A> From looking at the wiki page it's not exactly clear what your plan is A> regarding the accessor functions as they stand today (if_get*/if_set* A> after drvapi change was made). I briefly glanced through some of the code A> changes but that takes time so it'd be good to know sort of the overall A> plan in that area if you foresee major rework. The plan is that they go away. They were a quick solution, that allow to avoid recompilation of a driver when struct ifnet change, but they still dictate the layout of the structure and don't give enough flexibility for the stacj to change in future. Also, new world order dictates that all change to flags/capenable/etc go directly through if_ioctl, so that we have one place to catch all events. Field accessor functions violate this rule. -- Totus tuus, Glebius.