Date: Fri, 2 Jun 1995 15:28:58 +0800 (WST) From: Peter Wemm <peter@haywire.DIALix.COM> To: hackers@FreeBSD.ORG Subject: Size of SIOCGIFCONF ioctl data structure Message-ID: <Pine.SV4.3.91.950602143106.16692C-100000@haywire.DIALix.COM>
next in thread | raw e-mail | index | archive | help
Something interesting was bought up on the bind-workers mailing list.. Bind was getting a truncated list of interfaces (it bind()'s to them all so that it can handle multi-homed hosts correctly). Anyway, there is no way to calculate how much is *enough* space to pass for the buffer. One if the solutions proposed is to use a while loop, malloc'ing a larger buffer each time around and doing the ioctl(s, SIOCGIFCONF, &ifr) each time until it gets a non-truncated list. Sun (In solaris 2.3) have added a SIOCGIFNUM ioctl, that returns the number of interfaces, so that the request buffer can be appropriately sized in one go, rather than going over and over the loop. What would be the chances of adding such an ioctl to FreeBSD? Since FreeBSD can return variable sized ifreq structures with larger addresses for various address family types, something would have to be done there. There'd be two ways around it.. 1: Calculate the number of bytes and divide it by the basic size of the structure (and round up), so that programs like named could so "bufsize = nif * sizeof(struct ifreq) + FUDGE_FACTOR; " 2: Introduce Yet Another (TM) ioctl that returns the number of bytes. Yes, I know there's the sysctl() way of doing it, but I don't think that would make it into Paul Vixie's release for a while. There's many other generic programs "out there" that could also benefit from this, where the author's are not prepared to dump the existing code and rewrite it from scratch to the 4.4bsd way of doing it This affects people that are running machines with lots of aliases on their ethernet addresses for things like web servers, as well as people running lots of slip/ppp/tun interfaces. Opinions? -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.91.950602143106.16692C-100000>