From owner-freebsd-hackers Thu Oct 16 19:00:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09985 for hackers-outgoing; Thu, 16 Oct 1997 19:00:50 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA09974 for ; Thu, 16 Oct 1997 19:00:42 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id MAA27628; Fri, 17 Oct 1997 12:00:25 +1000 From: Darren Reed Message-Id: <199710170200.MAA27628@plum.cyber.com.au> Subject: Re: Freebsd 3.0 current fails ipfilter 3.2b8 build (fwd) To: julian@whistle.com (Julian Elischer) Date: Fri, 17 Oct 1997 12:00:24 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <3446B81E.4DAA423A@whistle.com> from "Julian Elischer" at Oct 16, 97 05:58:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Julian Elischer, sie wrote > > > okay, this is the second time you're referred to the API. > > > > Where can it be found ? Who is responsible for it ? > > > It's a slow thing. Just a general consencus that lookingin the kernel vm > for information is notthe way to go in general. Granted. > Netstat still does, but that is hoped to go away as we make > more API methods to allow this to be changed. I can see creaping featurisms here...I'd like to see the API designed first, with it reviewed before people start making ad-hoc changes which are "generally in line with our goals". > the aim is to stop anything from needing to do 'kread()' calls > to get status. Hmmm...see below. > I enclose a little program that dumps out all the > interface addresses and flags without reading the kernel. > > I find it very hard to believe you don't know about this.. as I > know you are very knowledgeable on the networking, and I guess we > are somehow talking on cross purposes (porpoises?). [...] I've seen that ioctl used before...it's not one of my favourites, that's for sure! If I have 256 interfaces, the program you posted breaks. Maybe there should be a sysctl which returns the number of interfaces available, so you can correctly size the ioctl ? (of course this means a variable which has this stored). Of course, to correctly size the ioctl, you could walk the kernel list first ;) This is sort of what I'm getting at with API design. There's an interface present, but using it isn't 100% safe to use.