From owner-freebsd-net@FreeBSD.ORG Wed Feb 25 22:17:47 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 59044F9A; Wed, 25 Feb 2015 22:17:47 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 BB5A91E9; Wed, 25 Feb 2015 22:17:46 +0000 (UTC) Received: by lams18 with SMTP id s18so7119192lam.11; Wed, 25 Feb 2015 14:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ehVDh+dZz5XzbqTPgyNVhQMDB6B0hGYGlnQNl5aXvzg=; b=J0pFXpfd+Niavq4VJufPKlkKMhkXmHkT6YrZv+EETpcZUTlOiYILMgidLMNd8CSaVh C4MywqW9MlpvNgLqjmqhDB+ya/3j0AJJOLOuGTTzCOXY40+YpyIJl4AD6IAtpHLC3aMR M8fQtXH2pLQjE7UVjkzUuzJnGZ0+jNn6Ifgirp93SEDb8JF7bhQL2rFTRsIXmAoOq0Gh dcXvIbd7CNTBdbEbeaj2+CrZd19golYkhg9Z41quD2RxHD7V7+kdvM+LhJodmqzM/9sb PAbOFZsMAelfr7YaK3kYF7MCPCC/ze/irU3LcB2EFn68Zk6HcMuWw0rUZ2EHgWC/F7gi Sv/A== MIME-Version: 1.0 X-Received: by 10.112.169.39 with SMTP id ab7mr4662205lbc.85.1424902664816; Wed, 25 Feb 2015 14:17:44 -0800 (PST) Received: by 10.112.173.199 with HTTP; Wed, 25 Feb 2015 14:17:44 -0800 (PST) In-Reply-To: <20150225221120.GC17947@FreeBSD.org> References: <201502170150.t1H1ouxM020621@mail.karels.net> <20150225221120.GC17947@FreeBSD.org> Date: Wed, 25 Feb 2015 14:17:44 -0800 Message-ID: Subject: Re: Adding new media types to if_media.h From: Jack Vogel To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Mike Karels , "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: Wed, 25 Feb 2015 22:17:47 -0000 So we have products coming soon that need to extend the media, if you have grandiose plans in the future you can worry about things then, Linux can handle the extended media TODAY, wouldn't it be nice to do so as well? Also, this solution is something that can be MFC'd into 10 STABLE, if you do something big in the 11 stream I will be that wont be possible, so I'd say lets do this as a first step. Jack On Wed, Feb 25, 2015 at 2:11 PM, Gleb Smirnoff wrote: > On Mon, Feb 16, 2015 at 07:50:56PM -0600, Mike Karels wrote: > M> Well, I developed the prototype as I had planned, using a 64-bit media > M> word, and found that I got about 100 files in GENERIC that didn't > compile; > M> they attempted to store "media words" in an int. My kingdom for a > typedef. > M> That didn't meet my goal of KPI compatibility, so I went to Plan B. > M> > M> Plan B is to steal an unused bit (RFU) to indicate an "extended" media > M> type. I then used the variant/subtype field to store the extended type. > M> Effectively, the previously unused bit doubles the effective size of the > M> subtype field. Given that the previous 5-bit field lasted us 18 years, > M> I figured that doubling it would last a while. I also changed the > M> SIOGGIFMEDIA ioctl, splitting it for binary compatibility; extended > M> types are all mapped to IFM_OTHER (31) using the old interface, but > M> are visible using the new one. > M> > M> With these changes, I modified one driver (vtnet) to use an extended > type, > M> and the rest of GENERIC is happy. The changes to ifconfig are also > fairly > M> small. The patch is appended, where email programs will screw it up, > M> or at ftp://ftp.karels.net/outgoing/if_media.patch. > M> > M> The VFAST subtype is a throw-away for testing. > M> > M> This seems like a reasonably pragmatic change to support the new 40 Gb/s > M> media types until someone wants to design an improved but non-backward- > M> compatible interface. I think it meets the goal of suitability for > M> back-porting; it could be MFCed. > > I will dare to vote against the crowd. > > We can't and don't plan to preserve the driver KPI for the 11 branch. The > plan, that I hope to accomplish by 11 is to provide a driver KPI, where > drivers do not about struct ifnet, and other network stack stuff. Of > course, that's a huge change in KPI. But we do it for the sake to avoid > future changes. > > So, all this tricks with one extra bit seem unnecessary to me. I'd suggest > to introduce new 'struct ifmedia' with enough space, and of course put > extra > space in there. Give a new value to SIOCGIFMEDIA. Write a new clear code > to handle it, without any extended bit tricks. > > For the sake of userland API, save old current 'struct ifmedia' as > 'struct oifmedia', and take old value of ioctl to OSIOCIGIFMEDIA. > Write a function under BURN_BRIDGES that handles OSIOCIGIFMEDIA and > tries to convert from ifmedia to oifmedia, > > To summarise: the patch adds tricks to just double the ifmedia name space, > not solving the problem forever. New API is introduced, but old limited one > doesn't have foreseable obsolete plan, since new is tied to it. All tricks > are performed for the sake of driver KPI stability, which isn't planned > to be kept for this major release cycle. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >