From owner-freebsd-embedded@FreeBSD.ORG Tue Dec 13 15:45:56 2011 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA1CF106566B; Tue, 13 Dec 2011 15:45:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5BD8E8FC14; Tue, 13 Dec 2011 15:45:56 +0000 (UTC) Received: from [10.0.0.150] (150.imp.bsdimp.com [10.0.0.150] (may be forged)) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBDFf1Ub061614 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 13 Dec 2011 08:41:04 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <55D569DB-875B-412B-8650-C56F85D8E327@lassitu.de> Date: Tue, 13 Dec 2011 08:41:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <96F0A4F9-671B-422C-B8F2-6F386B1B3672@bsdimp.com> References: <68ABED76-CB1F-405A-8036-EC254F7511FA@lassitu.de> <3B3DB17D-BF87-40EE-B1C1-445F178E8844@lassitu.de> <86030CEE-6839-4B96-ACDC-2BA9AC1E4AE4@lassitu.de> <2D625CC9-A0E3-47AA-A504-CE8FB2F90245@lassitu.de> <203BF1C8-D528-40C9-8611-9C7AC7E43BAB@lassitu.de> <3C0E9CA3-E130-4E9A-ABCC-1782E28999D1@lassitu.de> <6387ABA5-AC55-49DD-9058-E45CC0A3E0A0@lassitu.de> <74E4AF57-3D22-415E-B913-176753B09B16@lassitu.de> <710E2C7A-E9AC-4103-8C61-0EDC4A3AF9DE@lassitu.de> <24FB4633-B729-4582-9FF6-CA8656742985@lassitu.de> <55D569DB-875B-412B-8650-C56F85D8E327@lassitu.de> To: Stefan Bethke X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 13 Dec 2011 08:41:04 -0700 (MST) Cc: Adrian Chadd , freebsd-embedded@FreeBSD.org Subject: Re: TL-WR1043: switch X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 15:45:56 -0000 On Dec 13, 2011, at 1:00 AM, Stefan Bethke wrote: >=20 > Am 13.12.2011 um 02:41 schrieb Adrian Chadd: >=20 >> Hm, it seems your etherswitchcfg code is reusing code from ifconfig? >> Or is that code from ray? >>=20 >> Just a nitpick, we should likely avoid that code duplication and >> either roll this into ifconfig, or should we just break out the >> ifconfig related code into a shared library and reuse that? >=20 > Ultimately, that would be the correct way. I'd start working on that = once it's clear that this is the way forward. >=20 > Integrating the switch configuration code into ifconfig has crossed my = mind, but I think the overlap is too small to make sense. While the = media code manipulates the same data structures (struct ifreq, struct = ifmediareq), the ioctls are completely different, so much of the = ifconfig infrastructure is actually in the way. >=20 > I'm using sbin/ifconfig/if_media.c unchanged except for exporting some = of the low level functions for printing and parsing media and mediaopt. = I'm not certain where this code would go to be shared efficiently. = Also, wherever it goes ifconfig still needs to be buildable for /rescue. Unless the code is huge, I'd like to see it in ifconfig as well from a = usability standpoint. Why require yet another application to do this? = We put all the wireless stuff into ifconfig. If the infrastructure really is getting in the way, I'd like to look at = ways to make ifconfig more flexible and less in the way. Warner