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 [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
