From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 08:57:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF67E1065673; Wed, 25 Jan 2012 08:57:36 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 76AF08FC1B; Wed, 25 Jan 2012 08:57:36 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 35843A0D9; Wed, 25 Jan 2012 08:57:33 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Wed, 25 Jan 2012 09:57:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Aleksandr Rybalko , freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 08:57:36 -0000 Am 25.01.2012 um 08:12 schrieb Adrian Chadd: > So when will you two have something consensus-y to commit? :-) >=20 > What I'm hoping for is: >=20 > * some traction on the MII bus / MDIO bus split and tidyup from stb, = which is nice; > * ray's switch API for speaking to userland with; > * agreeing on whether the correct place to put the driver(s) is where = stb, ray, or a mix of both approaches says so. >=20 > I've been (mostly) trying to stay out of this to see where both of you = have gone. I think we've made some good progress; now it's time to = solidify a design for the first pass of what we want in -HEAD and figure = out how to move forward. My suggestion is to take my bus attachment code (incl. mdio and = miiproxy) and ray's ioctl and userland code. Aleksandr's approach for the driver attachment is to have a generic = switch "bus" driver that abstracts the mii, i2c, memory mapped I/O, etc. = busses the devices are physically attached to, and present a uniform = register file to the chip-specific switch driver. I believe that this = is unnecessarily complicated for two reasons: newbus already provides = that abstraction, and chip-specific drivers usually differ in so many = aspects, including their register files, that code sharing between chips = will be somewhat limited anyway. One aspect that I would enjoy looking into in more detail is how = register accesses on, for example, MDIO, can be provided through the bus = space API. =46rom my cursory reading, it seems that the code currently = is tailored towards register accesses that can be implemented through = CPU native instructions, instead of indirectly through a controller. Aleksandr has defined a quite comprehensive ethernet switch control API = that the framework provides towards in-kernel clients as well as = userland. I think it would be really helpful if we could concentrate on = those API functions that can be controlled through the userland utility, = have immediate use cases (for example, VLAN configuration on the = TL-WR1043ND to separate the WAN from the LAN ports), and we have test = hardware for. In short, don't commit dead code. Having a description of the generic switch model that the API assumes = and driver-specific documentation also wouldn't hurt. (Yes, I'm = volunteering.) Stefan --=20 Stefan Bethke Fon +49 151 14070811