network interfaces. This works by pre-computing the pseudo-header
checksum and caching it, delaying the actual checksum to ip_output()
if the hardware cannot perform the sum for us. In-bound checksums
can either be fully-checked by hardware, or summed up for final
verification by software. This method was modeled after how this
is done in FreeBSD, although the code is significantly different in
most places.
We don't delay checksums for IPv6/TCP, but we do take advantage of the
cached pseudo-header checksum.
Note: hardware-assisted checksumming defaults to "off". It is
enabled with ifconfig(8). See the manual page for details.
Implement hardware-assisted checksumming on the DP83820 Gigabit Ethernet,
3c90xB/3c90xC 10/100 Ethernet, and Alteon Tigon/Tigon2 Gigabit Ethernet.
enabling the INET6_MD_CKSUM option, which is defopted into opt_inet.h.
Supply an i386 assembly version of in6_cksum in in_cksum.s; on
P6-family cpu's, this is is roughly 20% faster than the C code in
sys/netinet6 for ethernet-mtu-sized mbufs in L1 cache. Turn on
INET6_MD_CKSUM in i386/conf/std.i386
While we're here, also nuke some now-obsolete XXX comments from
in_cksum.s.
This is based on amiga's siop driver, but converted to use
bus_space(9) functions and modified to fit bus_dma(9) framework.
Currently tested on NetBSD/arc with jazzio 53c710 SCSI,
which really requires bus_dma(9) functions :-)
Sync transfers and disconnect/reconnect are also working.
TODO:
- Test under more heavy load
- Clean up osiop_checkintr() hander
- Reorganize command queue and sync negotiation handling more suitable
for thorpej-scsipi mid-layer
- Re-think defered interrupt handling for amiga
based on the existing net/if_spppsubr.c stuff.
While there are completely userland (bpf based) implementations available,
those have a vastly larger per packet overhead thus causing major CPU
overhead and higher latency. On an i386 base router, running a 486DX at 50MHz
my line (768kBit/s downstream) was limited to something (varying) between 10
and 20 kByte/s effective download rate. With this implementation I get full
bandwidth (~85kByte/s).
This is client side only. Arguably the right way to add full PPPoE support
(including server side) would be a variation of the ppp line discipline and
appropriate modifications to pppd. I promise every help I can give to anyone
doing that - but I needed this realy fast. Besids, on low memory NAT boxes
with typically a single PPPoE connection, this implementation is more
lightweight than a pppd based one, which nicely fits my needs.
This now provides slightly more functionality than the FreeBSD layer1-newbus
interface. It was meant to be a simple change to one header and a few
c files, but the change rippled all through various stuff.
To prevent a change to the kernel<->userland interface right now the kernel
is now lying about card types to userland (but who cares). This will be fixed
when the userland interface changes, after layer 3 <-> layer 4 has been
fixed.
Functional changes:
Provide a clean interface for hardware drivers to attach to the upper
layers. This will need another small change in the B-channel handling
when a similar change to the layer 3 <-> layer 4 interface happens.
Avoid passing indices into global arrays of pointers around, instead pass
the pointers itself. Don't code hardware driver types by predefined magic
numbers (think LKM). Prepare for detachable drivers (think pcmcia).
While there remove some sets of function pointers always pointing to the
same function (meant to be the configurable set of D channel protocol
handlers). It is unlikely another supported D-channel protocol will fit into
that (maximal layer interface) abstraction. When we get support for another
protocol, we will need to come up with a workable interface. Besides, the
old implementation was, uhm, strange.
including layer_*.c if "options LKM". This is not the right way to fix
it, but we have as yet no standardized mechanism to add a "LKM code
library" to fill in gaps in the monolithic kernel's code.
Problem noted by <tron@netbsd.org>.
This is the kernel part (userland to follow soon) of the latest (and
very probably last) release (version 0.96) of ISDN4BSD. ISDN4BSD has a
homepage at http://www.freebsd-support.de/i4b/.
It gives the user various ways to use the isdn connection: raw data (via
the i4brbch "raw b-channel" device), ppp (via the isp "isdn PPP" device),
voice/answering machine (the i4btel "telephone" device) and ip over isdn
(the ipr device, "IP over raw ISDN").
Supported are a bunch of common and older cards, more to be added soon
after some cleanup. Currently only the european E-DSS1 variant of the
ISDN D channel protocol is supported.
pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
This is very adhoc work for IETF meeting.
- Since it seems that 'an' and 'wi' have similar hardware, low level
functions should be shared.
- There are PCI/ISA cards of Aironet but not supported yet.
- The wiconfig interface is changed so that wiconfig cannot be used.
- 'ancontrol' of FreeBSD is not ported.
- Only infrastructure mode is tested.
- WEP is not supported.
Though I only have an Aironet card, Cisco card should be expected to work.
tsutsui