Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 23:38:43 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h926c425007239 for ; Wed, 1 Oct 2003 23:38:04 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h926c0qU019463 for ; Thu, 2 Oct 2003 06:38:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h926WSg06951 for ; Thu, 2 Oct 2003 06:32:28 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100123375217636 ; Wed, 01 Oct 2003 23:37:54 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: "Jay Vosburgh" , "David S. Miller" , "Chad N. Tindel" , , , Subject: Re: [Bonding-devel] Re: [bonding] compatibilty issues Date: Thu, 2 Oct 2003 09:37:51 +0300 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200310020937.51781.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1119 Lines: 26 On Wednesday 01 October 2003 10:25 pm, Jay Vosburgh wrote: > Same here, but I'd like to have a list somewhere of what each > of the ABI versions is for and how they're supposed to behave. > It's starting to look like we're going to be adding these on a > semi-regular basis, so we need to keep track of what each one does > and why. > Where should such a list go ? Currently, 0 or none is for doing everything the old way. 1 is for not setting slaves HW addr via ifenslave and leaving them in down state so the driver gets them with their unique address, sets them according to the mode and brings them up. The driver also restores the original address upon release. This is all done for supporting the 802.3ad, TLB, ALB modes. 2 will be for ifenslave lite that doesn't propagate the bond's IP settings to the slaves. I'm guessing that 3 will be used to designate the new support for hot operations that Amir is working on. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. |