From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 03:45:57 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A55076FF; Mon, 9 Feb 2015 03:45:57 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B5E0C53; Mon, 9 Feb 2015 03:45:57 +0000 (UTC) Received: by iecrd18 with SMTP id rd18so1602163iec.8; Sun, 08 Feb 2015 19:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ktt/HK4RMTZXQp75yruCb+atLFWMJmcGH8YZYBHyAP0=; b=LRa2zKbEa1YI4SbLWaYIq/XsYMVgI6JduUYniaMGNJS+Q0T7+Y6a2a07BtXshGdEMA rBFRysFk7a3vdTmjUk37EQCNPRxjP2gMRMa0XEuY2ndJksKxbTNEAD06Dr4dqmVtJp5g P8HExi78DPtBvAkUMT/QVUx+eBoND1/fYhr5zonyWs6CUXFIMW/rVuW4CUeOjN/VtuhD OtjTNLtVuGE25t6Wl0uqLxK588Ux3ixri2pg7SUKJjyawrLmUNIyZ2ORZ0lzQA+pJnPX vW3V/iyFk4cOb7uNohEMFNMJe6pEt41ylcGbnoCicCIHlSFhcOIs2yGDL2+Q+YZkC5IK d6pg== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr14523191igb.6.1423453556085; Sun, 08 Feb 2015 19:45:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Sun, 8 Feb 2015 19:45:55 -0800 (PST) In-Reply-To: <201502090249.t192nI96091798@mail.karels.net> References: <54D805D1.4050008@freebsd.org> <201502090249.t192nI96091798@mail.karels.net> Date: Sun, 8 Feb 2015 19:45:55 -0800 X-Google-Sender-Auth: 8Byr6a0ac5s-R62D_nu5_aTw7d0 Message-ID: Subject: Re: Fwd: Adding new media types to if_media.h From: Adrian Chadd To: mike@karels.net Content-Type: text/plain; charset=UTF-8 Cc: Rui Paulo , "freebsd-net@freebsd.org" , Alfred Perlstein , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 03:45:57 -0000 Hey, don't worry about the wifi side of things - I have absolutely no requirement for backwards compatible API/ABI in the net80211 stack outside of "it makes my life as the maintainer painful." I'm happy to go churn it as part of this in order to get things looking better. (And I likely have to at some point in the future when 11ac support turns up.) -a On 8 February 2015 at 18:49, Mike Karels wrote: > Alfred wrote: >> On 2/8/15 2:41 PM, Mike Karels wrote: >> > >> > To solve the second problem, I think the right approach would be to reduce >> > this interface to a truly generic one, such as media type (e.g. Ethernet), >> > generic flags, and perhaps generic status. Then there should be a separate >> > media-specific interface for each type, such as Ethernet and 802.11. To a >> > small extent, we already have that. Solving the second, more general problem, >> > requires a whole new driver KPI that will require surgery to every driver, >> > which is not an exercise that I would consider. >> > >> > >> > I am willing to do a prototype for -current for evaluation. >> > >> > Comments, alternatives, ? >> Mike, > >> I think we have enough people to chip in that your concern about >> breaking the KPI is not as bad as you think. > >> Would like to hear the first correct + long term + less hackish proposal >> first. > >> Norse has a kernel team that is heavily invested in networking that can >> help with the transition. > >> If done right, likely renaming ALL of the macros it will be quite >> trivial to catch all bad cases and move us forward in one great leap. > > Don't forget that the KPI is not the only part. Breaking the user-level > interface (API/ABI are almost the same) gets into ports and other important > software that is harder to change. A new KPI could still provide a compatible > API, but would be much constrained. And fwiw, I don't see the advantage to > be gained unless the 802.11 software would be much improved. I'm not the > one to weigh in on that. > > Mike