d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
d707ae5ef8
freebsd-skq/sys/net/if_tap.h

75 lines
2.5 KiB
C
Raw Normal View History

/* -> /*- for license, minor formatting changes
2005-01-07 01:45:51 +00:00
/*-
sys: general adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. No functional change intended.
2017-11-27 15:23:17 +00:00
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
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
2000-07-20 17:01:10 +00:00
* Copyright (C) 1999-2000 by Maksim Yevmenkin <m_evmenkin@yahoo.com>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* BASED ON:
* -------------------------------------------------------------------------
*
* Copyright (c) 1988, Julian Onions <jpo@cs.nott.ac.uk>
* Nottingham University 1987.
*/
/*
* $FreeBSD$
* $Id: if_tap.h,v 0.7 2000/07/12 04:12:51 max Exp $
*/
#ifndef _NET_IF_TAP_H_
#define _NET_IF_TAP_H_
tun/tap: merge and rename to `tuntap` tun(4) and tap(4) share the same general management interface and have a lot in common. Bugs exist in tap(4) that have been fixed in tun(4), and vice-versa. Let's reduce the maintenance requirements by merging them together and using flags to differentiate between the three interface types (tun, tap, vmnet). This fixes a couple of tap(4)/vmnet(4) issues right out of the gate: - tap devices may no longer be destroyed while they're open [0] - VIMAGE issues already addressed in tun by kp [0] emaste had removed an easy-panic-button in r240938 due to devdrn blocking. A naive glance over this leads me to believe that this isn't quite complete -- destroy_devl will only block while executing d_* functions, but doesn't block the device from being destroyed while a process has it open. The latter is the intent of the condvar in tun, so this is "fixed" (for certain definitions of the word -- it wasn't really broken in tap, it just wasn't quite ideal). ifconfig(8) also grew the ability to map an interface name to a kld, so that `ifconfig {tun,tap}0` can continue to autoload the correct module, and `ifconfig vmnet0 create` will now autoload the correct module. This is a low overhead addition. (MFC commentary) This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this, and how critical they are. Changes after this are likely easily MFC'd without taking this merge, but the merge will be easier. I have no plans to do this MFC as of now. Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill) Input also from: melifaro Relnotes: yes Differential Revision: https://reviews.freebsd.org/D20044
2019-05-08 02:32:11 +00:00
#include <net/if_tun.h>
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
2000-07-20 17:01:10 +00:00
/* maximum receive packet size (hard limit) */
#define TAPMRU 16384
tun/tap: merge and rename to `tuntap` tun(4) and tap(4) share the same general management interface and have a lot in common. Bugs exist in tap(4) that have been fixed in tun(4), and vice-versa. Let's reduce the maintenance requirements by merging them together and using flags to differentiate between the three interface types (tun, tap, vmnet). This fixes a couple of tap(4)/vmnet(4) issues right out of the gate: - tap devices may no longer be destroyed while they're open [0] - VIMAGE issues already addressed in tun by kp [0] emaste had removed an easy-panic-button in r240938 due to devdrn blocking. A naive glance over this leads me to believe that this isn't quite complete -- destroy_devl will only block while executing d_* functions, but doesn't block the device from being destroyed while a process has it open. The latter is the intent of the condvar in tun, so this is "fixed" (for certain definitions of the word -- it wasn't really broken in tap, it just wasn't quite ideal). ifconfig(8) also grew the ability to map an interface name to a kld, so that `ifconfig {tun,tap}0` can continue to autoload the correct module, and `ifconfig vmnet0 create` will now autoload the correct module. This is a low overhead addition. (MFC commentary) This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this, and how critical they are. Changes after this are likely easily MFC'd without taking this merge, but the merge will be easier. I have no plans to do this MFC as of now. Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill) Input also from: melifaro Relnotes: yes Differential Revision: https://reviews.freebsd.org/D20044
2019-05-08 02:32:11 +00:00
#define tapinfo tuninfo
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
2000-07-20 17:01:10 +00:00
tun/tap: merge and rename to `tuntap` tun(4) and tap(4) share the same general management interface and have a lot in common. Bugs exist in tap(4) that have been fixed in tun(4), and vice-versa. Let's reduce the maintenance requirements by merging them together and using flags to differentiate between the three interface types (tun, tap, vmnet). This fixes a couple of tap(4)/vmnet(4) issues right out of the gate: - tap devices may no longer be destroyed while they're open [0] - VIMAGE issues already addressed in tun by kp [0] emaste had removed an easy-panic-button in r240938 due to devdrn blocking. A naive glance over this leads me to believe that this isn't quite complete -- destroy_devl will only block while executing d_* functions, but doesn't block the device from being destroyed while a process has it open. The latter is the intent of the condvar in tun, so this is "fixed" (for certain definitions of the word -- it wasn't really broken in tap, it just wasn't quite ideal). ifconfig(8) also grew the ability to map an interface name to a kld, so that `ifconfig {tun,tap}0` can continue to autoload the correct module, and `ifconfig vmnet0 create` will now autoload the correct module. This is a low overhead addition. (MFC commentary) This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this, and how critical they are. Changes after this are likely easily MFC'd without taking this merge, but the merge will be easier. I have no plans to do this MFC as of now. Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill) Input also from: melifaro Relnotes: yes Differential Revision: https://reviews.freebsd.org/D20044
2019-05-08 02:32:11 +00:00
/*
* ioctl's for get/set debug; these are aliases of TUN* ioctls, see net/if_tun.h
* for details.
*/
#define TAPSDEBUG TUNSDEBUG
#define TAPGDEBUG TUNGDEBUG
#define TAPSIFINFO TUNSIFINFO
#define TAPGIFINFO TUNGIFINFO
Add new TAPGIFNAME tap(4) character device ioctl. This is a convenient shortcut to obtain network interface name using file descriptor for character device. Obtained from: NetBSD MFC after: 1 week
2008-09-08 22:43:55 +00:00
#define TAPGIFNAME _IOR('t', 93, struct ifreq)
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
2000-07-20 17:01:10 +00:00
/* VMware ioctl's */
Fix our ioctl(2) implementation when the argument is "int". New ioctls passing integer arguments should use the _IOWINT() macro. This fixes a lot of ioctl's not working on sparc64, most notable being keyboard/syscons ioctls. Full ABI compatibility is provided, with the bonus of fixing the handling of old ioctls on sparc64. Reviewed by: bde (with contributions) Tested by: emax, marius MFC after: 1 week
2006-09-27 19:57:02 +00:00
#define VMIO_SIOCSIFFLAGS _IOWINT('V', 0)
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
2000-07-20 17:01:10 +00:00
#define VMIO_SIOCSKEEP _IO('V', 1)
#define VMIO_SIOCSIFBR _IO('V', 2)
#define VMIO_SIOCSLADRF _IO('V', 3)
/* XXX -- unimplemented */
#define VMIO_SIOCSETMACADDR _IO('V', 4)
/* XXX -- not used? */
#define VMIO_SIOCPORT _IO('V', 5)
#define VMIO_SIOCBRIDGE _IO('V', 6)
#define VMIO_SIOCNETIF _IO('V', 7)
#endif /* !_NET_IF_TAP_H_ */
Reference in New Issue Copy Permalink