<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/net/Makefile, branch v4.4.2</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.2</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.2'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2015-08-24T21:06:33Z</updated>
<entry>
<title>fjes: Introduce FUJITSU Extended Socket Network Device driver</title>
<updated>2015-08-24T21:06:33Z</updated>
<author>
<name>Taku Izumi</name>
<email>izumi.taku@jp.fujitsu.com</email>
</author>
<published>2015-08-21T08:29:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=658d439b22924796d00f03282135a356f47cc64e'/>
<id>urn:sha1:658d439b22924796d00f03282135a356f47cc64e</id>
<content type='text'>
This patch adds the basic code of FUJITSU Extended Socket
Network Device driver.

When "PNP0C02" is found in ACPI DSDT, it evaluates "_STR"
to check if "PNP0C02" is for Extended Socket device driver
and retrieves ACPI resource information. Then creates
platform_device.

Signed-off-by: Taku Izumi &lt;izumi.taku@jp.fujitsu.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Introduce VRF device driver</title>
<updated>2015-08-14T05:43:22Z</updated>
<author>
<name>David Ahern</name>
<email>dsa@cumulusnetworks.com</email>
</author>
<published>2015-08-13T20:59:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=193125dbd8eb292d88feb201f030889b488b0a02'/>
<id>urn:sha1:193125dbd8eb292d88feb201f030889b488b0a02</id>
<content type='text'>
This driver borrows heavily from IPvlan and teaming drivers.

Routing domains (VRF-lite) are created by instantiating a VRF master
device with an associated table and enslaving all routed interfaces that
participate in the domain. As part of the enslavement, all connected
routes for the enslaved devices are moved to the table associated with
the VRF device. Outgoing sockets must bind to the VRF device to function.

Standard FIB rules bind the VRF device to tables and regular fib rule
processing is followed. Routed traffic through the box, is forwarded by
using the VRF device as the IIF and following the IIF rule to a table
that is mated with the VRF.

Example:

   Create vrf 1:
     ip link add vrf1 type vrf table 5
     ip rule add iif vrf1 table 5
     ip rule add oif vrf1 table 5
     ip route add table 5 prohibit default
     ip link set vrf1 up

   Add interface to vrf 1:
     ip link set eth1 master vrf1

Signed-off-by: Shrijeet Mukherjee &lt;shm@cumulusnetworks.com&gt;
Signed-off-by: David Ahern &lt;dsa@cumulusnetworks.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>geneve: add initial netdev driver for GENEVE tunnels</title>
<updated>2015-05-13T19:59:13Z</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2015-05-13T16:57:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2d07dc79fe04a43d82a346ced6bbf07bdb523f1b'/>
<id>urn:sha1:2d07dc79fe04a43d82a346ced6bbf07bdb523f1b</id>
<content type='text'>
This is an initial implementation of a netdev driver for GENEVE
tunnels.  This implementation uses a fixed UDP port, and only supports
point-to-point links with specific partner endpoints.  Only IPv4
links are supported at this time.

Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipvlan: Initial check-in of the IPVLAN driver.</title>
<updated>2014-11-24T20:29:18Z</updated>
<author>
<name>Mahesh Bandewar</name>
<email>maheshb@google.com</email>
</author>
<published>2014-11-24T07:07:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2ad7bf3638411cb547f2823df08166c13ab04269'/>
<id>urn:sha1:2ad7bf3638411cb547f2823df08166c13ab04269</id>
<content type='text'>
This driver is very similar to the macvlan driver except that it
uses L3 on the frame to determine the logical interface while
functioning as packet dispatcher. It inherits L2 of the master
device hence the packets on wire will have the same L2 for all
the packets originating from all virtual devices off of the same
master device.

This driver was developed keeping the namespace use-case in
mind. Hence most of the examples given here take that as the
base setup where main-device belongs to the default-ns and
virtual devices are assigned to the additional namespaces.

The device operates in two different modes and the difference
in these two modes in primarily in the TX side.

(a) L2 mode : In this mode, the device behaves as a L2 device.
TX processing upto L2 happens on the stack of the virtual device
associated with (namespace). Packets are switched after that
into the main device (default-ns) and queued for xmit.

RX processing is simple and all multicast, broadcast (if
applicable), and unicast belonging to the address(es) are
delivered to the virtual devices.

(b) L3 mode : In this mode, the device behaves like a L3 device.
TX processing upto L3 happens on the stack of the virtual device
associated with (namespace). Packets are switched to the
main-device (default-ns) for the L2 processing. Hence the routing
table of the default-ns will be used in this mode.

RX processins is somewhat similar to the L2 mode except that in
this mode only Unicast packets are delivered to the virtual device
while main-dev will handle all other packets.

The devices can be added using the "ip" command from the iproute2
package -

	ip link add link &lt;master&gt; &lt;virtual&gt; type ipvlan mode [ l2 | l3 ]

Signed-off-by: Mahesh Bandewar &lt;maheshb@google.com&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Maciej Żenczykowski &lt;maze@google.com&gt;
Cc: Laurent Chavey &lt;chavey@google.com&gt;
Cc: Tim Hockin &lt;thockin@google.com&gt;
Cc: Brandon Philips &lt;brandon.philips@coreos.com&gt;
Cc: Pavel Emelianov &lt;xemul@parallels.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: reduce USB network driver config options.</title>
<updated>2014-08-05T23:48:59Z</updated>
<author>
<name>Francois Romieu</name>
<email>romieu@fr.zoreil.com</email>
</author>
<published>2014-08-05T21:10:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1bb5a356c3ea6e633908e0ebd6695b13debc3d86'/>
<id>urn:sha1:1bb5a356c3ea6e633908e0ebd6695b13debc3d86</id>
<content type='text'>
USB network drivers are already handled in drivers/net/usb/Kconfig.
Let's save the maintenance burden of dependencies in drivers/net/Makefile.

The newly introduced USB_NET_DRIVERS umbrella config option defaults
to 'y' so as to minimize the changes of behavior.

Signed-off-by: Francois Romieu &lt;romieu@fr.zoreil.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: remove spurious zd1201 rule.</title>
<updated>2014-08-04T22:02:54Z</updated>
<author>
<name>Francois Romieu</name>
<email>romieu@fr.zoreil.com</email>
</author>
<published>2014-08-04T21:47:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9041263ca9128b9f54fce9c215b09850615ff810'/>
<id>urn:sha1:9041263ca9128b9f54fce9c215b09850615ff810</id>
<content type='text'>
Leftover from 5c601d0c942f5aaf7f3cff7e08f61047d70a964e ("wireless: move
zd1201 where it belongs").

Signed-off-by: Francois Romieu &lt;romieu@fr.zoreil.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>packet: nlmon: virtual netlink monitoring device for packet sockets</title>
<updated>2013-06-24T23:39:05Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2013-06-21T17:38:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e4fc408e0e99fd2e009c8b3702d9637f5554fd5c'/>
<id>urn:sha1:e4fc408e0e99fd2e009c8b3702d9637f5554fd5c</id>
<content type='text'>
Currently, there is no good possibility to debug netlink traffic that
is being exchanged between kernel and user space. Therefore, this patch
implements a netlink virtual device, so that netlink messages will be
made visible to PF_PACKET sockets. Once there was an approach with a
similar idea [1], but it got forgotten somehow.

I think it makes most sense to accept the "overhead" of an extra netlink
net device over implementing the same functionality from PF_PACKET
sockets once again into netlink sockets. We have BPF filters that can
already be easily applied which even have netlink extensions, we have
RX_RING zero-copy between kernel- and user space that can be reused,
and much more features. So instead of re-implementing all of this, we
simply pass the skb to a given PF_PACKET socket for further analysis.

Another nice benefit that comes from that is that no code needs to be
changed in user space packet analyzers (maybe adding a dissector, but
not more), thus out of the box, we can already capture pcap files of
netlink traffic to debug/troubleshoot netlink problems.

Also thanks goes to Thomas Graf, Flavio Leitner, Jesper Dangaard Brouer.

 [1] http://marc.info/?l=linux-netdev&amp;m=113813401516110

Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Add support for NTB virtual ethernet device</title>
<updated>2013-01-18T03:11:14Z</updated>
<author>
<name>Jon Mason</name>
<email>jon.mason@intel.com</email>
</author>
<published>2012-11-17T02:27:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=548c237c0a9972df5d1afaca38aa733ee577128d'/>
<id>urn:sha1:548c237c0a9972df5d1afaca38aa733ee577128d</id>
<content type='text'>
A virtual ethernet device that uses the NTB transport API to
send/receive data.

Signed-off-by: Jon Mason &lt;jon.mason@intel.com&gt;
Reviewed-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Acked-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vxlan: virtual extensible lan</title>
<updated>2012-10-01T22:39:45Z</updated>
<author>
<name>stephen hemminger</name>
<email>shemminger@vyatta.com</email>
</author>
<published>2012-10-01T12:32:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d342894c5d2f8c7df194c793ec4059656e09ca31'/>
<id>urn:sha1:d342894c5d2f8c7df194c793ec4059656e09ca31</id>
<content type='text'>
This is an implementation of Virtual eXtensible Local Area Network
as described in draft RFC:
  http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02

The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality
that learns MAC to IP address mapping.

This implementation has not been tested only against the Linux
userspace implementation using TAP, not against other vendor's
equipment.

Signed-off-by: Stephen Hemminger &lt;shemminger@vyatta.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>drivers/ieee802154: move ieee802154 drivers to net folder</title>
<updated>2012-08-30T17:23:56Z</updated>
<author>
<name>alex.bluesman.smirnov@gmail.com</name>
<email>alex.bluesman.smirnov@gmail.com</email>
</author>
<published>2012-08-26T05:10:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0739d643b8dda866d1011bcfd01008d29593be03'/>
<id>urn:sha1:0739d643b8dda866d1011bcfd01008d29593be03</id>
<content type='text'>
The IEEE 802.15.4 standard represents a networking protocol. I don't
exactly know why drivers for this protocol are stored into the root
'driver' folder, but better will be to store them with other
networking stuff. Currently there are only 3 drivers available for
IEEE 802.15.4 stack, so lets do it now with the smallest overhead.

Signed-off-by: Alexander Smirnov &lt;alex.bluesman.smirnov@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
