--=-=-=
Content-Transfer-Encoding: quoted-printable


Pavel Cahyna <pavel@netbsd.org> writes:

> Why do the 802.11 drivers use ether_output and other Ethernet routines
> if the frames are actually in a different format? FDDI and Token Ring also
> have their own _output routines. Shouldn't we have a similar
> ieee80211_output function which would be used instead of ether_output?

Probably.  Basically 802.11 is designed to be bridged to Ethernet, and
most programs treat it like an ethernet, so my take is that 802.11
support in *BSD presents an Ethernet-like interface.  The basic type
of 802.11 devices is DLT_EN10MB.

The odd bit is that the packets in the output queue are in Ethernet
format instead of 802.11 format, and the start routine does the encap.

An alternative is to have a new output routine for 802.11 that does
the encap and have the output queue then be in 802.11 format.

That would still leave us with the question of how to handle different
DLTs on output, since an 802.11 device would have to handle bpf writes
with type DLT_EN10MB.  So the part of Vivek's proposal that adds a
write callback to the bpf attachment would remain; we'd just move the
encap in the processing chain and change the rules for the output
queue.  But then we could skip the raw output queue and just put
packets in the output queue.  We probably then have to factor out the
part of ether_output that does encap from the part that puts packets
on queues.

An issue here is FreeBSD divergence, so I'd be particularly interested
in Sam's thoughts.

On balance, I don't see the need to change 802.11 device's output
queues to have 802.11 encap at the same time as adding the output
ability - the changes are 95% orthogonal.

=2D-=20
    Greg Troxel <gdt@ir.bbn.com>

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)

iD8DBQFEz6eA+vesoDJhHiURAg/bAJ4vELkNgAoYqPwuGuHWmrjsDK5L5ACfUNio
APRjDeKa8MwXDXU4bxwV7t4=
=Hprq
-----END PGP SIGNATURE-----
--=-=-=--