Date: Mon, 27 Sep 1999 21:37:23 -0400 From: "Donald J . Maddox" <dmaddox@conterra.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: current@FreeBSD.ORG Subject: Re: Demand-loaded network ifs and bpf Message-ID: <19990927213722.A2334@dmaddox.conterra.com> In-Reply-To: <19990927165321.43140@hydrogen.fircrest.net> References: <19990926145328.A430@dmaddox.conterra.com> <19990927165321.43140@hydrogen.fircrest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990927213722.A2334>