Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Revert part of an earlier patch attempt that snuck in with r240938.

Avoid INVARIANTS panic destroying an in-use tap(4)

The requirement (implied by the KASSERT in tap_destroy) that the tap is
closed isn't valid; destroy_dev will block in devdrn while other threads
are in d_* functions.

Note: if_tun had the same issue, addressed in SVN revisions r186391,
r186483 and r186497. The use of the condvar there appears to be
redundant with the functionality provided by destroy_dev.

Sponsored by: ADARA Networks
Reviewed by: dwhite
MFC after: 2 weeks

Stop embedding struct ifnet at the top of driver softcs. Instead the
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.

This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.

Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.

Reviewed by: sobomax, sam

/* -> /*- for license, minor formatting changes

Do the dreaded s/dev_t/struct cdev */
Bump __FreeBSD_version accordingly.

Add tap_mtx to tap_softc in order to protect per-softc variables
(tap_pid, tap_flags). if_tap should now be entirely MPSAFE.

Committed from: Bamboo house by ocean in Taiwan
Tropical paradise provided by: Chia-liang Kao <clkao@clkao.org>

Remove stale (unused) unit variables from if_tun and if_tap softc's.

Device megapatch 2/6:

This commit adds a couple of functions for pseudodrivers to use for
implementing cloning in a manner we will be able to lock down (shortly).

Basically what happens is that pseudo drivers get a way to ask for
"give me the dev_t with this unit number" or alternatively "give
me a dev_t with the lowest guaranteed free unit number" (there is
unfortunately a lot of non-POLA in the exact numeric value of this
number, just live with it for now)

Managing the unit number space this way removes the need to use
rman(9) to do so in the drivers this greatly simplifies the code in
the drivers because even using rman(9) they still needed to manage
their dev_t's anyway.

I have taken the if_tun, if_tap, snp and nmdm drivers through the
mill, partly because they (ab)used makedev(), but mostly because
together they represent three different problems for device-cloning:

if_tun and snp is the plain case: just give me a device.

if_tap has two kinds of devices, with a flag for device type.

nmdm has paired devices (ala pty) can you can clone either of them.

Add cloning support for the tap(4) device similar to that in the tun(4)
device.

Submitted by: Maksim Yevmenkin <myevmenk@digisle.net>

Change to support vmware... SIOCSIFADDR on the character device
sets the (notional) "remote" ethernet address.

Submitted by: vsilyaev@mindspring.com

Sundry changes to debugging code.
Add spl/splx to various sensitive spots
Change semantics of the vmnet version of the device to keep VMware happy
(don't junk state when the device is closed)

Submitted by: vsilyaev@mindspring.com

Add the tap driver.

The tap driver is used to present a virtual Ethernet interface to the
system. Packets presented by the network stack to the interface are
made available to a character device in /dev. With tap and the bridge
code, you can make remote bridge configurations where both sides of
the bridge are separated by userland daemons.

This driver also has a special naming hack to allow it to serve a similar
purpose to the vmware port.

Submitted by: myevmenkin@att.com, vsilyaev@mindspring.com