Date: Wed, 15 Dec 1999 02:16:31 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: brian@Awfulhak.org (Brian Somers) Cc: jlemon@americantv.com, brian@Awfulhak.org, imp@village.org, freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org Subject: Re: The if_detach problem Message-ID: <199912150216.TAA17370@usr08.primenet.com> In-Reply-To: <199912142322.XAA36949@hak.lan.Awfulhak.org> from "Brian Somers" at Dec 14, 99 11:22:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Right, but how about a ``notthere'' flag instead ? A "virtual interface"? This plays havoc with default routes. > My concern is that there are some APIs that use interface ids > (sysctl(PF_ROUTE) springs to mind) and some APIs that use > interface names (the struct ifaliasreq ioctls etc) and reassigning > the association between the two on the fly seems a tad dangerous - > lots of races. I think the answer is as obvious as "ps" and "libkvm": data interfaces suck, and procedureal interfaces don't. > Another (more real?) argument for keeping the interface but making it > unusable 'till the driver wants it again is that there may be > security concerns.... at the moment, ``netstat -i'' reports what's > been going on very nicely. Removing the interface entirely will > allow people to hide what should not be hidden.... ??? Doug Ambrisko is running wireless in the office right now with a PCMCIA card. It's unreasonable to not allow him to switch between a wireless adapter and a docking bay or other PCMCIA card as his default route as it becomes available. I think that the routing table and other information needs to be correct, more than it needs to be historically accurate. For netstat -i, if you destroy the object on which you are keeping statistics, it's right to destroy the statistics information as well. Consider that packets sent, collisions, and similar counts are not presistant across a reboot (in which interfaces are "deinstanced" and subsequently "reinstanced"). I know there's a lot of cached state issues, but like "ps", this isn't a very good reason to _not_ fix them. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912150216.TAA17370>