From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 22:51:09 2015 Return-Path: Delivered-To: freebsd-net@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 7F8EBBAD; Tue, 6 Jan 2015 22:51:09 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4376EA7C; Tue, 6 Jan 2015 22:51:09 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id et14so662831pad.3; Tue, 06 Jan 2015 14:51:08 -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:from:date:message-id :subject:to:cc:content-type; bh=4SQvoNOexqCzMGszZZ+YXu9qjH4PB0YrUb99epCa/NQ=; b=MLYqA08tpZfW3b/KQ1uxabWL2zqtt2DEQdMWp75P6Zf9B3kmtHGQAlgEssx5lDyJ+M MQUKerOP/saWugo11gcAxnlN0R+DGqqR6lAJSsIglywOAdLt3r4UAkOBGrTcOMdXOAUK 1P9VmbzblFz9bTbtgcS+S6ZUVCOVCyppZvti2sLroHwIuPr1gnHXtscFEKhALq2gK9ND 6ScI2GWc6s8rsrAhGirwKKsWx+sFLw4ymHig5E1cxwMZZTjtv5v8Hfb2fHkWP6P0yH/b A1R7XM5dTnOD362FM7gLK7XJ/WnvmbJh4SX7EFzv4c8g6jxusBXLioyc6cuM8iYr2343 NVyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erj.cc; s=ericroxx; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4SQvoNOexqCzMGszZZ+YXu9qjH4PB0YrUb99epCa/NQ=; b=rFrBsV4aBVqY+t+pm55ToPCafZNeEWaqJMIVVUkaWr6Tz9j73i7JU5U+iJe9S7iYJ9 Un5Q3Ej0C81zxbfe/imDovu3KeplGxfwxnKcuTSZ8nUIJY8NA22lZVdbRjvom1c4IiZd QB76YPCvqctkzGA+qnmEuh53t90UHZP9hSH2E= X-Received: by 10.66.141.197 with SMTP id rq5mr112415979pab.118.1420584668801; Tue, 06 Jan 2015 14:51:08 -0800 (PST) MIME-Version: 1.0 Sender: ricera10@gmail.com Received: by 10.70.89.209 with HTTP; Tue, 6 Jan 2015 14:50:28 -0800 (PST) In-Reply-To: <201412130106.sBD16tgl072730@mail.karels.net> References: <2116096.l1vR0RuKRU@ralph.baldwin.cx> <201412130106.sBD16tgl072730@mail.karels.net> From: Eric Joyner Date: Tue, 6 Jan 2015 14:50:28 -0800 X-Google-Sender-Auth: ipy0MCiE36PaVM6w-CtdKxEn9js Message-ID: Subject: Re: Adding new media types to if_media.h To: mike@karels.net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , 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: Tue, 06 Jan 2015 22:51:09 -0000 Then going with what Mike says about leaving backwards compatibility, I suppose we should do something like what Adrian suggested, and add a separate struct. We can indicate that the separate struct exists by setting the media type value in the if_media word to 0xc0, since that's the last unused value. Then existing programs won't have to support any new features if they don't want to. Adrian -- where can I look for more information on what net80211 does for media types? Do you mean what it does with MCS values, or something more; I've looked at it a bit, but I don't know very much about how Wi-Fi works. - Eric On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels wrote: > > 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 >