From owner-freebsd-hackers Mon Oct 8 11:53:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A234A37B407; Mon, 8 Oct 2001 11:53:33 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f98IrWf39097; Mon, 8 Oct 2001 14:53:32 -0400 (EDT) (envelope-from wollman) Date: Mon, 8 Oct 2001 14:53:32 -0400 (EDT) From: Garrett Wollman Message-Id: <200110081853.f98IrWf39097@khavrinen.lcs.mit.edu> To: Yar Tikhiy Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Some thoughts on if_ioctl() In-Reply-To: <20011008113214.A68390@snark.rinet.ru> References: <20011008113214.A68390@snark.rinet.ru> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < said: > Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI. > There is code obviously taken from if_loop.c and used in some > drivers, which tries to do something with the third argument "data" > of the if_ioctl() driver method if "data" isn't NULL. The historic implementation passed SIOCADDMULTI directly down to the interface to implement, which resulted in lots of duplicated code all over the place to manage the list of multicast addresses. Several years ago, I rewrote the multicast management code to simply indicate to the driver when the list has changed, obviating the need for the driver itself to manage the list. > If I understand the kernel code right, if_ioctl()'s third argument > is always NULL Not so. Any ioctl() in class 'i' which is not handled by the generic code will get passed down to the driver to handle; some of these requests may require the data pointer. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message