Date: Wed, 10 Oct 2001 19:32:56 +0400 From: Yar Tikhiy <yar@FreeBSD.ORG> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Some thoughts on if_ioctl() Message-ID: <20011010193256.A64375@snark.rinet.ru> In-Reply-To: <200110081853.f98IrWf39097@khavrinen.lcs.mit.edu> References: <20011008113214.A68390@snark.rinet.ru> <200110081853.f98IrWf39097@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 08, 2001 at 02:53:32PM -0400, Garrett Wollman wrote:
> <<On Mon, 8 Oct 2001 11:32:14 +0400, Yar Tikhiy <yar@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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011010193256.A64375>