From owner-freebsd-current Mon Sep 27 18:37:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from hawaii.conterra.com (hawaii.conterra.com [209.12.164.32]) by hub.freebsd.org (Postfix) with ESMTP id 0A1701565E for ; Mon, 27 Sep 1999 18:37:20 -0700 (PDT) (envelope-from myself@conterra.com) Received: from dmaddox.conterra.com (root@dmaddox.conterra.com [209.12.169.48]) by hawaii.conterra.com (8.9.3/8.9.3) with ESMTP id VAA11967; Mon, 27 Sep 1999 21:37:18 -0400 (EDT) Received: (from myself@localhost) by dmaddox.conterra.com (8.9.3/8.9.1) id VAA02609; Mon, 27 Sep 1999 21:37:23 -0400 (EDT) (envelope-from myself) Date: Mon, 27 Sep 1999 21:37:23 -0400 From: "Donald J . Maddox" To: John-Mark Gurney Cc: current@FreeBSD.ORG Subject: Re: Demand-loaded network ifs and bpf Message-ID: <19990927213722.A2334@dmaddox.conterra.com> Reply-To: dmaddox@conterra.com References: <19990926145328.A430@dmaddox.conterra.com> <19990927165321.43140@hydrogen.fircrest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19990927165321.43140@hydrogen.fircrest.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for the info. I do read the commit logs, and I was aware of this commit; however, it's not entirely clear to me if this commit resolves the issue I'm talking about. The problem, as I recall, had to do with the bpf pseudo-device attaching to devices _only_ at boot time, so it would not see any device loaded after boot. The specific case for me was, I compiled a kernel with bpf support, but no tun device. Then, after 'kldload'ing if_tun.ko, attempting to run 'tcpdump -i tun0' gave: tcpdump: tun0: Device not configured The tun0 commit that paralells the one you quoted, says: --------------------------------------------------------------------------- ... Remove NBPF conditionality of bpf calls in most of our network drivers. This means that we will not have to have a bpf and a non-bpf version of our driver modules. This does not open any security hole, because the bpf core isn't loadable ... ------------------------------------------------------------------------- Maybe I'm just not reading enough into this, but this commit does not seem to address the problem I had. I never had a non-bpf version of the tun module. In any case, the issue is easily resolvable. I will just build a kernel with bpf and no tun0, and see if 'tun0 as kld' works with bpf :-) On Mon, Sep 27, 1999 at 04:53:21PM -0700, John-Mark Gurney wrote: > Donald J . Maddox scribbled this message on Sep 26: > > I see that support has been added for demand-loading network > > if drivers. I seem to recall that the last time I tried using > > network drivers as klds, nothing that required bpf to work > > was functional anymore, because bpf required that the device > > existed at the time it was initialized. Is this still the case? > > Will bpf work for demand-loaded network klds? > > you should do your own research such are reading the commit logs that > has to deal with it (remeber, you're suppose to be reading them if you > are running -current): > wpaul 1999/09/22 20:32:59 PDT > > Modified files: > sys/pci if_al.c if_ax.c if_dm.c if_mx.c if_pn.c > if_rl.c if_sf.c if_sis.c if_sk.c if_ste.c > if_ti.c if_tl.c if_vr.c if_wb.c if_xl.c > sys/i386/isa if_wi.c > Log: > As suggested by phk, unconditionalize BPF support in these drivers. Since > there are stubs compiled into the kernel if BPF support is not enabled, > there aren't any problems with unresolved symbols. The modules in /modules > are compiled with BPF support enabled anyway, so the most this will do is > bloat GENERIC a little. > > -- > John-Mark Gurney Voice: +1 408 975 9651 > Cu Networking > > "The soul contains in itself the event that shall presently befall it. > The event is only the actualizing of its thought." -- Ralph Waldo Emerson > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message