Re: Demand-loaded network ifs and bpf
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 GurneyVoice: +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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Demand-loaded network ifs and bpf
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 GurneyVoice: +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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
