* libcsupport/include/sys/ioccom.h, libnetworking/kern/uipc_socket2.c,
libnetworking/net/ethernet.h, libnetworking/net/if.h,
libnetworking/net/if_ethersubr.c, libnetworking/net/if_ppp.c,
libnetworking/net/if_pppvar.h, libnetworking/net/ppp_tty.c,
libnetworking/net/pppcompress.c, libnetworking/net/slcompress.c,
libnetworking/netinet/in.h, libnetworking/netinet/ip_icmp.c,
libnetworking/netinet/tcp.h, libnetworking/netinet/tcp_seq.h,
libnetworking/sys/protosw.h, libnetworking/sys/socketvar.h: Remove
warnings. Most of the warnings were 16/32 bit integer sizing issues.
Some constants had L appended, some had casts add, some types were
changed to reflect a bit width requirement.
* libnetworking/net/if.h: Add forward reference declaration to
struct mbuf so ifru_tap callback is properly typed.
* libnetworking/rtems/rtems_bsdnet.h: Add definition of _BSD_VISIBLE
which needs to be defined so various pieces of the .h files are
visible to device drives.
allows one to trace the enqueueing and dequeueing of messages. This
can be used to insure that packets are getting to the boundary between
the network stack and the device driver.
From: Eric Norum <eric@skatter.usask.ca>
Date: Sat, 5 Dec 98 13:20:51 -0600
What do you think of this patch? It implements your `tap'
suggestion in a way that adds support for all ethernet devices with
no driver modifications. I also added a return value from the tap
function. If the return value is zero, the packet will be passed up
the chain as usual. If the return value is non-zero the mbuf holding
the packet will be freed and the packet will be dropped.
If you like it, please submit it to Joel.
I guess there needs to be an addition to the network documentation
describing the additional ioctl's -- and a big warning that the tap
function is called from a context that holds the network semaphore.
Here is Eric's patch. I've tested it a bit, and made a couple of
trivial changes. This is certainly better than mine: it should work
for all Ethernet drivers.
==================================================
The only concern I have about this patch is that the tap function may
want to fiddle with the mbuf, calling functions like m_pullup and the
like. If those force the networking code to rearrange the mbuf
structure, then the caller's call to m_freem may crash. I don't know
if this is a realistic concern--I don't know enough about the mbuf
layer.
