On Mon, Oct 08, 2001 at 02:53:32PM -0400, Garrett Wollman wrote:
> <<On Mon, 8 Oct 2001 11:32:14 +0400, Yar Tikhiy <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
