So, when working on an driver for an 802.11 card, I realized that we could
eliminate a bunch of duplicated code in drivers and sys/net.

This all has to do with 802.x framing vs. ethernet framing.

Traditional ethernet just has a 2-byte ethernet type field followed by
the ethernet payload.

there's also the more complex 802.x framing scheme (which can be used
on ethernet, but isn't, normally, at least for IP), which replaces the
ethernet type with a 2-byte length field (the possible values of which
are fortunately not valid ethertypes), and then follows it with an LLC
header, which includes a source and destination protocol id ("LSAP")
(why anyone would want to send a packet from X.25 to IP is beyond me,
but I digress..).

To make life more interesting, one possible LLC type is a "SNAP"
header, which can contain an ethernet protocol type..

Other 802.x media (including token ring, fddi, 802.11, and apparently
some ATM encapsulations) always start off their packets with LLC
headers.

To simplify this mess, I think we should split ether_input up into
three functions:

1) ether_input (ifp, m)
	does what it does now, up until the "switch (etype)"

	adjust packet to point just past ethertype/length
	if etype >= ETHERTYPE_MIN ('traditional ethernet'), call
		ethertype_input (ifp, etype, m)
	else {
		trim packet to the specified length
		call ieee802_input (ifp, m)
	}

2) ethertype_input(ifp, etype, m)
	contains the big "switch on ethertype" code.

3) ieee802_input (ifp, m)
	assumes that the current start of the mbuf now points at the
	LLC header, and parses that.
	if it finds a SNAP header which contains an ethertype, it
		adjusts the header to point just past the SNAP header, 
			and calls ethertype_input(ifp, ether, m .... )
	for other LSAP types (X.25 and ISO) it does what ether_input
		currently does.

We can then fix up if_fddisubr.c and if_tokensubr.c and a forthcoming
if_80211subr.c to call ieee802_input() instead of having
near-identical copies of code in them.

Thoughts?

					- Bill