On Fri, Jan 18, 2002 at 03:23:09PM +0100, Harti Brandt wrote: > On Fri, 18 Jan 2002, Ruslan Ermilov wrote: > > RE>On Fri, Jan 18, 2002 at 10:41:58AM +0100, Harti Brandt wrote: > RE>> On Fri, 18 Jan 2002, Ruslan Ermilov wrote: > RE>> > RE>> RE>On Thu, Jan 17, 2002 at 06:58:26PM +0100, Harti Brandt wrote: > RE>> RE>> > RE>> RE>> Hi, > RE>> RE>> > RE>> RE>> how is a daemon supposed to get informed that a network interface has been > RE>> RE>> created? I had hoped, that an RTM_IFINFO message would be created on the > RE>> RE>> routing socket, but this is not the case. If an interface is destroyed, > RE>> RE>> the routing socket gets a message for whatever reason. Wouldn't it be > RE>> RE>> simple to just create an RTM_IFINFO message? > RE>> RE>> > RE>> RE>It does get created (you can check with the ``route -vn monitor'' command), > RE>> RE>but please see PR kern/33747 for one small pitfall. > RE>> > RE>> That's exactly what I did, but it doesn't work. The only places, that I > RE>> can find when rt_ifmsg is called are: > RE>> > RE>> - interface goes up (if_route) > RE>> - interface goes down (if_unroute) > RE>> - change MTU (if_hwioctl) > RE>> - prom. mode (ifpromisc) > RE>> - allmulti (if_allmulti) > RE>> > RE>> No one seems to call it when I just create an interface. The RTM_IFINFO > RE>> when I delete it probably comes from the if_unroute. The RTM_IFINFO you > RE>> see for an ifconfig gif0 create is probably a side effect of setting the > RE>> MTU or so. > RE>> > RE>> I think it would make sense to do an rt_ifmsg somehere in > RE>> if_attach/if_detach. > RE>> > RE>OK, I will send a patch within an hour or so. NetBSD already > RE>has something to address this. > > I just had a look at this and, yes, that's what I mean. > I've just committed this feature.
> Just one question: > is there any locking that does a user process prevent from seeing the > interface still on the interface list after the message is sent, but > before the interface is removed from the list? (I mean on an SMP system). > The DEPARTURE message is sent before the interface is unlinked from the > list. > In -STABLE, splnet() does the necessary locking. In SMPng'ed -CURRENT, I do not believe any ifnet-related mutexes code was committed. I think that the locking is done with Giant at the moment, but I may be wrong. In any case, the code I have committed does not make things any worse, as if_detach() should be able to modify the ifnet list of interfaces, and any ifnet-traversing code should block if the modification is in progress. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
