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

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

Reply via email to