>> where pr_usrreq(), in a call to manipulate a bridge device, will be a
>> udp socket, that means udp_usrreq() in netinet/udp_usrreq.c, which
>> does this:
>> 
>> 	if (req == PRU_CONTROL)
>> 		return (in_control(so, (long)m, (caddr_t)nam,
>> 		    (struct ifnet *)control, p));
>
>Oh, I see. That's why ioctl is associated with socket file 
>descriptor which is SOCK_DGRAM type.

sort of, yeah.  actually, if you follow this code path with your eyes,
you'll find that a socket of any INET type will (i think) end up doing
the same work at manipulating interfaces.  the socket interface just
makes for a convenient control point.

>> in_control() in netinet/in.c has a default case near the bottom of a
>> long switch that does this:
>> 
>>                 error = (*ifp->if_ioctl)(ifp, cmd, data);
>> 
>> and that's how bridge_ioctl() gets called.
>
>Thank you for clarification.

not at all.  i've been reading a lot of this stuff lately, so i've got
most of it in my head at the moment.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."