From owner-freebsd-arch@FreeBSD.ORG Sat Dec 13 01:07:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 202CA49F for ; Sat, 13 Dec 2014 01:07:02 +0000 (UTC) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id C7A20CC0 for ; Sat, 13 Dec 2014 01:07:01 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.7/8.14.7) with ESMTP id sBD16tgl072730; Fri, 12 Dec 2014 19:06:56 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201412130106.sBD16tgl072730@mail.karels.net> To: John Baldwin From: Mike Karels Reply-to: mike@karels.net Subject: Re: Adding new media types to if_media.h In-reply-to: Your message of Fri, 12 Dec 2014 15:31:06 -0500. <2116096.l1vR0RuKRU@ralph.baldwin.cx> Date: Fri, 12 Dec 2014 19:06:55 -0600 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , Jack Vogel , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 01:07:02 -0000 > On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: > > I think I'd go along with Mike, keeping it simpler seems like a good idea. > > > > Jack > If the userland ABI impact isn't too broad I think this is fine. Mike, do you > know off hand how many user-facing things would be affected? I didn't know off hand, but I have a glimpse index at $WORK (it's for McAfee Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 references to if_media.h at user level, including "ports" that we use, and excluding our own software. The list includes libpcap, snmpd, dhclient, quagga, xorp, atm, devd, and rtsold. fwiw, I found about 260 inclusions of if_media.h in the kernel. This suggests that we should preserve a backward-compatible user API, even if it has limits. Unfortunately, the media word I mentioned is a plain int, not a typedef. I would propose a similar API that is not limited, but easy to convert (e.g. using a new typedef). I'd be willing to sketch out something like that. > > On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: > > > > Any other thoughts, or should I start looking at seeing what I can take > > > > copy from net80211? > > > > > > > > Also adding -net, since this is pretty relevant. > > > > > > I had the same reaction as Adrian initially, as an int with numerous > > > fields > > > seems really messy. However, I don't think we have the challenges of > > > 802.11, > > > and the only real problem is that the subtype field has run out of bits. > > > And both ifconfig and the drivers are cast in the form of a scalar "media > > > word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | > > > IFM_FDX > > > (assuming that all the bits are in a scalar). > > > > > > Instead, I would propose that we simply change the media word from 32 bits > > > to 64, and move the subtype from its current location to a new field (e.g. > > > 16 bits) in the new space. I believe this can be KPI compatible, and it > > > is relatively easy to provide a backward-compatible ABI. There should be > > > a reserved subtype for "other" that can be encoded in the existing field > > > for use when the subtype can't fit in the old field. This seems much > > > easier, > > > can be KPI compatible, and will make it much easier to backport drivers. > > > A backport could simply define the new subtypes as "other", and the KPI > > > would still be compatible. > > > > > > Thoughts? > > > > > > Mike > -- > John Baldwin Mike