From owner-freebsd-hackers Wed Oct 10 8:33:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from snark.rinet.ru (snark.rinet.ru [195.54.192.73]) by hub.freebsd.org (Postfix) with ESMTP id C16E637B405; Wed, 10 Oct 2001 08:33:03 -0700 (PDT) Received: (from yar@localhost) by snark.rinet.ru (8.11.6/8.11.6) id f9AFWuT64862; Wed, 10 Oct 2001 19:32:56 +0400 (MSD) (envelope-from yar) Date: Wed, 10 Oct 2001 19:32:56 +0400 From: Yar Tikhiy To: Garrett Wollman Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Some thoughts on if_ioctl() Message-ID: <20011010193256.A64375@snark.rinet.ru> References: <20011008113214.A68390@snark.rinet.ru> <200110081853.f98IrWf39097@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110081853.f98IrWf39097@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.3.22.1i 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 On Mon, Oct 08, 2001 at 02:53:32PM -0400, Garrett Wollman wrote: > < 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. Sorry, I wrote an unclear phrase. I implied not all possible ioctl(2) requests, but only the SIOC{ADD|DEL}MULTI case. In that case, "data" seems to be always NULL since it's the way if_addmulti() and if_delmulti() call ifp->if_ioctl(), and there is no other way to pass SIOC{ADD|DEL}MULTI to a driver's if_ioctl(). If it's true, all the old ugly code about AF_INET and AF_INET6 multicast groups may be safely removed from the interface drivers. All the interface drivers will fall into two categories: - those which may simply do nothing on these requests (if_loop, if_sl...) - those which will rebuild some sort of a hardware multicast filter. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message