- 29 11月, 2005 1 次提交
-
-
由 Jeff Garzik 提交于
No need to record this information in source code, its all in the git repository, and kernel archives.
-
- 14 11月, 2005 1 次提交
-
-
由 Mitch Williams 提交于
Add the bond name to all error messages so we can tell which one is complaining. Also reformats some error messages to be more consistent. Signed-off-by: NMitch Williams <mitch.a.williams@intel.com> Acked-by: NJay Vosburgh <fubar@us.ibm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 8月, 2005 1 次提交
-
-
由 David S. Miller 提交于
Bonding just wants the device before the skb_bond() decapsulation occurs, so simply pass that original device into packet_type->func() as an argument. It remains to be seen whether we can use this same exact thing to get rid of skb->input_dev as well. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 27 6月, 2005 1 次提交
-
-
由 Jay Vosburgh 提交于
Add support for alternate slave selection algorithms to bonding balance-xor and 802.3ad modes. Default mode (what we have now: xor of MAC addresses) is "layer2", new choice is "layer3+4", using IP and port information for hashing to select peer. Originally submitted by Jason Gabler for balance-xor mode; modified by Jay Vosburgh to additionally support 802.3ad mode. Jason's original comment is as follows: The attached patch to the Linux Etherchannel Bonding driver modifies the driver's "balance-xor" mode as follows: - alternate hashing policy support for mode 2 * Added kernel parameter "xmit_policy" to allow the specification of different hashing policies for mode 2. The original mode 2 policy is the default, now found in xmit_hash_policy_layer2(). * Added xmit_hash_policy_layer34() This patch was inspired by hashing policies implemented by Cisco, Foundry and IBM, which are explained in Foundry documentation found at: http://www.foundrynet.com/services/documentation/sribcg/Trunking.html#112750Signed-off-by: NJason Gabler <jygabler@lbl.gov> Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-