From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 00:09:27 2015 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 E482D448; Wed, 7 Jan 2015 00:09:26 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (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 7574B646FF; Wed, 7 Jan 2015 00:09:26 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so248605wgg.19; Tue, 06 Jan 2015 16:09:24 -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=NS44vkc7bgIl/ds//nP+CVEerhOgsy/9PEhblCmvucY=; b=wrNWe6NaiRqhtuKuGZ53IdrZ5fL7V9bjrlh5FN/qW8fWVVv4fqcxAj8sIl+53b6QR+ WASwPUfkLCVFtB4PYa+EIH+sz5b5nAF8pxzFR/mAc7t5KL9J9qSW84I1XgPBXJj3e6lT fD1aZOHwCbh1Pq27lIxC+ZM2ZOyElev2dC+5DAJ0w/W/KYidNPLAi9SWFj9iwiBFhv7w 15anMI450a8Tq3PajKtXDVN0TaVOzcZRbSFsllhn136TUdRtGrRRaUh57DFwV7yxmW3r pY00YkTRQiTxpJzDvS2sHeDNJsNzIMwmg/zUgHKZhhEjG/K++Ok3dq+xIFP3FmlvV9Yo W7cA== MIME-Version: 1.0 X-Received: by 10.194.5.37 with SMTP id p5mr371489wjp.20.1420589364856; Tue, 06 Jan 2015 16:09:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Tue, 6 Jan 2015 16:09:24 -0800 (PST) In-Reply-To: References: <2116096.l1vR0RuKRU@ralph.baldwin.cx> <201412130106.sBD16tgl072730@mail.karels.net> Date: Tue, 6 Jan 2015 16:09:24 -0800 X-Google-Sender-Auth: zTxRoPSVw4orkcXeKarMLcJHczg Message-ID: Subject: Re: Adding new media types to if_media.h From: Adrian Chadd To: Eric Joyner Content-Type: text/plain; charset=UTF-8 Cc: mike@karels.net, Rui Paulo , "freebsd-net@freebsd.org" , John Baldwin , 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: Wed, 07 Jan 2015 00:09:27 -0000 On 6 January 2015 at 14:50, Eric Joyner wrote: > 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. Well, my idea is that there's parts of ifmedia that's related to the interface state that we care about, and some of it is just presentation related stuff that's opaque to the stack and only relevant for userland and for the driver/phy bits. The tricky bit is breaking the ifmedia API. It's not included as a pointer inside things - it's embedded as an actual struct. It's embedded inside net80211, but other than that and if_lagg I think it's mostly done inside drivers. So maybe we want to turn its use into allocate/free rather than embedded inside the struct; maybe we don't. Second is how we split up the bits that are mediatype-dependent versus the bits that are related to the network stack. My idea is just to break out each ifmedia field into an int each: * if_media Options word: * Bits Use * ---- ------- * 0-4 Media variant * 5-7 Media type * 8-15 Type specific options * 16-18 Mode (for multi-mode devices) * 19 RFU * 20-27 Shared (global) options * 28-31 Instance .. because I think it'll be easier in the long run to just have uint32_t fields for each of these. The general network stack shouldn't care about type, options and mode. It'll be a lot of churn, but I think it's cleaner than trying to continue doing dirty bitmap things. So: * do we break ifmedia use up into a pointer / allocated thing, rather than an embedded struct, with all the driver churn that'll entail; * do we just add a new field for type/options and have a magic type that's "other", or do we just go for breaking each option out into a field in a struct and have accessor methods to get access to things. What do people think? -adrian