linux/drivers/net/Kconfig

405 lines
14 KiB
Plaintext
Raw Normal View History

#
# Network device configuration
#
menuconfig NETDEVICES
default y if UML
depends on NET
bool "Network device support"
---help---
You can say N here if you don't intend to connect your Linux box to
any other computer at all.
You'll have to say Y if your computer contains a network card that
you want to use under Linux. If you are going to run SLIP or PPP over
telephone line or null modem cable you need say Y here. Connecting
two machines with parallel ports using PLIP needs this, as well as
AX.25/KISS for sending Internet traffic over amateur radio links.
See also "The Linux Network Administrator's Guide" by Olaf Kirch and
Terry Dawson. Available at <http://www.tldp.org/guides.html>.
If unsure, say Y.
# All the following symbols are dependent on NETDEVICES - do not repeat
# that for each of the symbols.
if NETDEVICES
config IFB
tristate "Intermediate Functional Block support"
depends on NET_CLS_ACT
---help---
This is an intermediate driver that allows sharing of
resources.
To compile this driver as a module, choose M here: the module
will be called ifb. If you want to use more than one ifb
device at a time, you need to compile this driver as a module.
Instead of 'ifb', the devices will then be called 'ifb0',
'ifb1' etc.
Look at the iproute2 documentation directory for usage etc
config DUMMY
tristate "Dummy net driver support"
---help---
This is essentially a bit-bucket device (i.e. traffic you send to
this device is consigned into oblivion) with a configurable IP
address. It is most commonly used in order to make your currently
inactive SLIP address seem like a real address for local programs.
If you use SLIP or PPP, you might want to say Y here. Since this
thing often comes in handy, the default is Y. It won't enlarge your
kernel either. What a deal. Read about it in the Network
Administrator's Guide, available from
<http://www.tldp.org/docs.html#guide>.
To compile this driver as a module, choose M here: the module
will be called dummy. If you want to use more than one dummy
device at a time, you need to compile this driver as a module.
Instead of 'dummy', the devices will then be called 'dummy0',
'dummy1' etc.
config BONDING
tristate "Bonding driver support"
depends on INET
depends on IPV6 || IPV6=n
---help---
Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
Channels together. This is called 'Etherchannel' by Cisco,
'Trunking' by Sun, 802.3ad by the IEEE, and 'Bonding' in Linux.
The driver supports multiple bonding modes to allow for both high
performance and high availability operation.
Refer to <file:Documentation/networking/bonding.txt> for more
information.
To compile this driver as a module, choose M here: the module
will be called bonding.
config MACVLAN
tristate "MAC-VLAN support (EXPERIMENTAL)"
depends on EXPERIMENTAL
---help---
This allows one to create virtual interfaces that map packets to
or from specific MAC addresses to a particular interface.
Macvlan devices can be added using the "ip" command from the
iproute2 package starting with the iproute2-2.6.23 release:
"ip link add link <real dev> [ address MAC ] [ NAME ] type macvlan"
To compile this driver as a module, choose M here: the module
will be called macvlan.
config MACVTAP
tristate "MAC-VLAN based tap driver (EXPERIMENTAL)"
depends on MACVLAN
help
This adds a specialized tap character device driver that is based
on the MAC-VLAN network interface, called macvtap. A macvtap device
can be added in the same way as a macvlan device, using 'type
macvlan', and then be accessed through the tap user space interface.
To compile this driver as a module, choose M here: the module
will be called macvtap.
config EQUALIZER
tristate "EQL (serial line load balancing) support"
---help---
If you have two serial connections to some other computer (this
usually requires two modems and two telephone lines) and you use
SLIP (the protocol for sending Internet traffic over telephone
lines) or PPP (a better SLIP) on them, you can make them behave like
one double speed connection using this driver. Naturally, this has
to be supported at the other end as well, either with a similar EQL
Linux driver or with a Livingston Portmaster 2e.
Say Y if you want this and read
<file:Documentation/networking/eql.txt>. You may also want to read
section 6.2 of the NET-3-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
To compile this driver as a module, choose M here: the module
will be called eql. If unsure, say N.
config TUN
tristate "Universal TUN/TAP device driver support"
select CRC32
---help---
TUN/TAP provides packet reception and transmission for user space
programs. It can be viewed as a simple Point-to-Point or Ethernet
device, which instead of receiving packets from a physical media,
receives them from user space program and instead of sending packets
via physical media writes them to the user space program.
When a program opens /dev/net/tun, driver creates and registers
corresponding net device tunX or tapX. After a program closed above
devices, driver will automatically delete tunXX or tapXX device and
all routes corresponding to it.
Please read <file:Documentation/networking/tuntap.txt> for more
information.
To compile this driver as a module, choose M here: the module
will be called tun.
If you don't know what to use this for, you don't need it.
config VETH
tristate "Virtual ethernet pair device"
---help---
This device is a local ethernet tunnel. Devices are created in pairs.
When one end receives the packet it appears on its pair and vice
versa.
config NET_SB1000
tristate "General Instruments Surfboard 1000"
depends on PNP
---help---
This is a driver for the General Instrument (also known as
NextLevel) SURFboard 1000 internal
cable modem. This is an ISA card which is used by a number of cable
TV companies to provide cable modem access. It's a one-way
downstream-only cable modem, meaning that your upstream net link is
provided by your regular phone modem.
At present this driver only compiles as a module, so say M here if
you have this card. The module will be called sb1000. Then read
<file:Documentation/networking/README.sb1000> for information on how
to use this module, as it needs special ppp scripts for establishing
a connection. Further documentation and the necessary scripts can be
found at:
<http://www.jacksonville.net/~fventuri/>
<http://home.adelphia.net/~siglercm/sb1000.html>
<http://linuxpower.cx/~cable/>
If you don't have this card, of course say N.
source "drivers/net/arcnet/Kconfig"
config MII
tristate "Generic Media Independent Interface device support"
help
Most ethernet controllers have MII transceiver either as an external
or internal device. It is safe to say Y or M here even if your
ethernet card lacks MII.
source "drivers/net/phy/Kconfig"
config SUNGEM_PHY
tristate
#
# Ethernet
#
source "drivers/net/ethernet/Kconfig"
source "drivers/net/fddi/Kconfig"
source "drivers/net/plip/Kconfig"
source "drivers/net/tokenring/Kconfig"
source "drivers/net/wireless/Kconfig"
source "drivers/net/wimax/Kconfig"
source "drivers/net/usb/Kconfig"
source "drivers/net/pcmcia/Kconfig"
source "drivers/net/ppp/Kconfig"
source "drivers/net/wan/Kconfig"
source "drivers/atm/Kconfig"
source "drivers/ieee802154/Kconfig"
source "drivers/s390/net/Kconfig"
source "drivers/net/caif/Kconfig"
config XEN_NETDEV_FRONTEND
tristate "Xen network device frontend driver"
depends on XEN
select XEN_XENBUS_FRONTEND
default y
help
xen network backend driver netback is the host side counterpart to the frontend driver in drivers/net/xen-netfront.c. The PV protocol is also implemented by frontend drivers in other OSes too, such as the BSDs and even Windows. The patch is based on the driver from the xen.git pvops kernel tree but has been put through the checkpatch.pl wringer plus several manual cleanup passes and review iterations. The driver has been moved from drivers/xen/netback to drivers/net/xen-netback. One major change from xen.git is that the guest transmit path (i.e. what looks like receive to netback) has been significantly reworked to remove the dependency on the out of tree PageForeign page flag (a core kernel patch which enables a per page destructor callback on the final put_page). This page flag was used in order to implement a grant map based transmit path (where guest pages are mapped directly into SKB frags). Instead this version of netback uses grant copy operations into regular memory belonging to the backend domain. Reinstating the grant map functionality is something which I would like to revisit in the future. Note that this driver depends on 2e820f58f7ad "xen/irq: implement bind_interdomain_evtchn_to_irqhandler for backend drivers" which is in linux next via the "xen-two" tree and is intended for the 2.6.39 merge window: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/backends this branch has only that single commit since 2.6.38-rc2 and is safe for cross merging into the net branch. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-03-15 00:06:18 +00:00
This driver provides support for Xen paravirtual network
devices exported by a Xen network driver domain (often
domain 0).
The corresponding Linux backend driver is enabled by the
CONFIG_XEN_NETDEV_BACKEND option.
If you are compiling a kernel for use as Xen guest, you
should say Y here. To compile this driver as a module, chose
M here: the module will be called xen-netfront.
config XEN_NETDEV_BACKEND
tristate "Xen backend network device"
depends on XEN_BACKEND
help
This driver allows the kernel to act as a Xen network driver
domain which exports paravirtual network devices to other
Xen domains. These devices can be accessed by any operating
system that implements a compatible front end.
The corresponding Linux frontend driver is enabled by the
CONFIG_XEN_NETDEV_FRONTEND configuration option.
The backend driver presents a standard network device
endpoint for each paravirtual network device to the driver
domain network stack. These can then be bridged or routed
etc in order to provide full network connectivity.
If you are compiling a kernel to run in a Xen network driver
domain (often this is domain 0) you should say Y here. To
compile this driver as a module, chose M here: the module
will be called xen-netback.
config RIONET
tristate "RapidIO Ethernet over messaging driver support"
depends on RAPIDIO
config RIONET_TX_SIZE
int "Number of outbound queue entries"
depends on RIONET
default "128"
config RIONET_RX_SIZE
int "Number of inbound queue entries"
depends on RIONET
default "128"
config SLIP
tristate "SLIP (serial line) support"
---help---
Say Y if you intend to use SLIP or CSLIP (compressed SLIP) to
connect to your Internet service provider or to connect to some
other local Unix box or if you want to configure your Linux box as a
Slip/CSlip server for other people to dial in. SLIP (Serial Line
Internet Protocol) is a protocol used to send Internet traffic over
serial connections such as telephone lines or null modem cables;
nowadays, the protocol PPP is more commonly used for this same
purpose.
Normally, your access provider has to support SLIP in order for you
to be able to use it, but there is now a SLIP emulator called SLiRP
around (available from
<ftp://ibiblio.org/pub/Linux/system/network/serial/>) which
allows you to use SLIP over a regular dial up shell connection. If
you plan to use SLiRP, make sure to say Y to CSLIP, below. The
NET-3-HOWTO, available from
<http://www.tldp.org/docs.html#howto>, explains how to
configure SLIP. Note that you don't need this option if you just
want to run term (term is a program which gives you almost full
Internet connectivity if you have a regular dial up shell account on
some Internet connected Unix computer. Read
<http://www.bart.nl/~patrickr/term-howto/Term-HOWTO.html>). SLIP
support will enlarge your kernel by about 4 KB. If unsure, say N.
To compile this driver as a module, choose M here. The module
will be called slip.
config SLIP_COMPRESSED
bool "CSLIP compressed headers"
depends on SLIP
select SLHC
---help---
This protocol is faster than SLIP because it uses compression on the
TCP/IP headers (not on the data itself), but it has to be supported
on both ends. Ask your access provider if you are not sure and
answer Y, just in case. You will still be able to use plain SLIP. If
you plan to use SLiRP, the SLIP emulator (available from
<ftp://ibiblio.org/pub/Linux/system/network/serial/>) which
allows you to use SLIP over a regular dial up shell connection, you
definitely want to say Y here. The NET-3-HOWTO, available from
<http://www.tldp.org/docs.html#howto>, explains how to configure
CSLIP. This won't enlarge your kernel.
config SLHC
tristate
help
This option enables Van Jacobsen serial line header compression
routines.
config SLIP_SMART
bool "Keepalive and linefill"
depends on SLIP
help
Adds additional capabilities to the SLIP driver to support the
RELCOM line fill and keepalive monitoring. Ideal on poor quality
analogue lines.
config SLIP_MODE_SLIP6
bool "Six bit SLIP encapsulation"
depends on SLIP
help
Just occasionally you may need to run IP over hostile serial
networks that don't pass all control characters or are only seven
bit. Saying Y here adds an extra mode you can use with SLIP:
"slip6". In this mode, SLIP will only send normal ASCII symbols over
the serial device. Naturally, this has to be supported at the other
end of the link as well. It's good enough, for example, to run IP
over the async ports of a Camtec JNT Pad. If unsure, say N.
config NET_FC
bool "Fibre Channel driver support"
depends on SCSI && PCI
help
Fibre Channel is a high speed serial protocol mainly used to connect
large storage devices to the computer; it is compatible with and
intended to replace SCSI.
If you intend to use Fibre Channel, you need to have a Fibre channel
adaptor card in your computer; say Y here and to the driver for your
adaptor below. You also should have said Y to "SCSI support" and
"SCSI generic support".
config NETCONSOLE
tristate "Network console logging support"
---help---
If you want to log kernel messages over the network, enable this.
See <file:Documentation/networking/netconsole.txt> for details.
[NET] netconsole: Support dynamic reconfiguration using configfs Based upon initial work by Keiichi Kii <k-keiichi@bx.jp.nec.com>. This patch introduces support for dynamic reconfiguration (adding, removing and/or modifying parameters of netconsole targets at runtime) using a userspace interface exported via configfs. Documentation is also updated accordingly. Issues and brief design overview: (1) Kernel-initiated creation / destruction of kernel objects is not possible with configfs -- the lifetimes of the "config items" is managed exclusively from userspace. But netconsole must support boot/module params too, and these are parsed in kernel and hence netpolls must be setup from the kernel. Joel Becker suggested to separately manage the lifetimes of the two kinds of netconsole_target objects -- those created via configfs mkdir(2) from userspace and those specified from the boot/module option string. This adds complexity and some redundancy here and also means that boot/module param-created targets are not exposed through the configfs namespace (and hence cannot be updated / destroyed dynamically). However, this saves us from locking / refcounting complexities that would need to be introduced in configfs to support kernel-initiated item creation / destroy there. (2) In configfs, item creation takes place in the call chain of the mkdir(2) syscall in the driver subsystem. If we used an ioctl(2) to create / destroy objects from userspace, the special userspace program is able to fill out the structure to be passed into the ioctl and hence specify attributes such as local interface that are required at the time we set up the netpoll. For configfs, this information is not available at the time of mkdir(2). So, we keep all newly-created targets (via configfs) disabled by default. The user is expected to set various attributes appropriately (including the local network interface if required) and then write(2) "1" to the "enabled" attribute. Thus, netpoll_setup() is then called on the set parameters in the context of _this_ write(2) on the "enabled" attribute itself. This design enables the user to reconfigure existing netconsole targets at runtime to be attached to newly-come-up interfaces that may not have existed when netconsole was loaded or when the targets were actually created. All this effectively enables us to get rid of custom ioctls. (3) Ultra-paranoid configfs attribute show() and store() operations, with sanity and input range checking, using only safe string primitives, and compliant with the recommendations in Documentation/filesystems/sysfs.txt. (4) A new function netpoll_print_options() is created in the netpoll API, that just prints out the configured parameters for a netpoll structure. netpoll_parse_options() is modified to use that and it is also exported to be used from netconsole. Signed-off-by: Satyam Sharma <satyam@infradead.org> Acked-by: Keiichi Kii <k-keiichi@bx.jp.nec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-08-10 22:35:05 +00:00
config NETCONSOLE_DYNAMIC
bool "Dynamic reconfiguration of logging targets"
netconsole: fix build when CONFIG_NETCONSOLE_DYNAMIC is turned on When NETCONSOLE_DYNAMIC=y and CONFIGFS_FS=m, there are build errors in netconsole: drivers/built-in.o: In function `drop_netconsole_target': netconsole.c:(.text+0x1a100f): undefined reference to `config_item_put' drivers/built-in.o: In function `make_netconsole_target': netconsole.c:(.text+0x1a10b9): undefined reference to `config_item_init_type_name' drivers/built-in.o: In function `write_msg': netconsole.c:(.text+0x1a11a4): undefined reference to `config_item_get' netconsole.c:(.text+0x1a1211): undefined reference to `config_item_put' drivers/built-in.o: In function `netconsole_netdev_event': netconsole.c:(.text+0x1a12cc): undefined reference to `config_item_put' netconsole.c:(.text+0x1a12ec): undefined reference to `config_item_get' netconsole.c:(.text+0x1a1366): undefined reference to `config_item_put' drivers/built-in.o: In function `init_netconsole': netconsole.c:(.init.text+0x953a): undefined reference to `config_group_init' netconsole.c:(.init.text+0x9560): undefined reference to `configfs_register_subsystem' drivers/built-in.o: In function `dynamic_netconsole_exit': netconsole.c:(.exit.text+0x809): undefined reference to `configfs_unregister_subsystem' so fix the NETCONSOLE_DYNAMIC depends clause to prevent this. Based on email suggestion from Ben Hutchings. Thanks. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=37992 Reported-by: David Hill <hilld@binarystorm.net> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-06-21 08:01:20 +00:00
depends on NETCONSOLE && SYSFS && CONFIGFS_FS && \
!(NETCONSOLE=y && CONFIGFS_FS=m)
[NET] netconsole: Support dynamic reconfiguration using configfs Based upon initial work by Keiichi Kii <k-keiichi@bx.jp.nec.com>. This patch introduces support for dynamic reconfiguration (adding, removing and/or modifying parameters of netconsole targets at runtime) using a userspace interface exported via configfs. Documentation is also updated accordingly. Issues and brief design overview: (1) Kernel-initiated creation / destruction of kernel objects is not possible with configfs -- the lifetimes of the "config items" is managed exclusively from userspace. But netconsole must support boot/module params too, and these are parsed in kernel and hence netpolls must be setup from the kernel. Joel Becker suggested to separately manage the lifetimes of the two kinds of netconsole_target objects -- those created via configfs mkdir(2) from userspace and those specified from the boot/module option string. This adds complexity and some redundancy here and also means that boot/module param-created targets are not exposed through the configfs namespace (and hence cannot be updated / destroyed dynamically). However, this saves us from locking / refcounting complexities that would need to be introduced in configfs to support kernel-initiated item creation / destroy there. (2) In configfs, item creation takes place in the call chain of the mkdir(2) syscall in the driver subsystem. If we used an ioctl(2) to create / destroy objects from userspace, the special userspace program is able to fill out the structure to be passed into the ioctl and hence specify attributes such as local interface that are required at the time we set up the netpoll. For configfs, this information is not available at the time of mkdir(2). So, we keep all newly-created targets (via configfs) disabled by default. The user is expected to set various attributes appropriately (including the local network interface if required) and then write(2) "1" to the "enabled" attribute. Thus, netpoll_setup() is then called on the set parameters in the context of _this_ write(2) on the "enabled" attribute itself. This design enables the user to reconfigure existing netconsole targets at runtime to be attached to newly-come-up interfaces that may not have existed when netconsole was loaded or when the targets were actually created. All this effectively enables us to get rid of custom ioctls. (3) Ultra-paranoid configfs attribute show() and store() operations, with sanity and input range checking, using only safe string primitives, and compliant with the recommendations in Documentation/filesystems/sysfs.txt. (4) A new function netpoll_print_options() is created in the netpoll API, that just prints out the configured parameters for a netpoll structure. netpoll_parse_options() is modified to use that and it is also exported to be used from netconsole. Signed-off-by: Satyam Sharma <satyam@infradead.org> Acked-by: Keiichi Kii <k-keiichi@bx.jp.nec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-08-10 22:35:05 +00:00
help
This option enables the ability to dynamically reconfigure target
parameters (interface, IP addresses, port numbers, MAC addresses)
at runtime through a userspace interface exported using configfs.
See <file:Documentation/networking/netconsole.txt> for details.
config NETPOLL
def_bool NETCONSOLE
config NETPOLL_TRAP
bool "Netpoll traffic trapping"
default n
depends on NETPOLL
config NET_POLL_CONTROLLER
def_bool NETPOLL
config VIRTIO_NET
tristate "Virtio network driver (EXPERIMENTAL)"
depends on EXPERIMENTAL && VIRTIO
---help---
This is the virtual network driver for virtio. It can be used with
lguest or QEMU based VMMs (like KVM or Xen). Say Y or M.
config VMXNET3
tristate "VMware VMXNET3 ethernet driver"
depends on PCI && INET
help
This driver supports VMware's vmxnet3 virtual ethernet NIC.
To compile this driver as a module, choose M here: the
module will be called vmxnet3.
endif # NETDEVICES