From owner-svn-src-head@FreeBSD.ORG Sat Sep 13 19:49:39 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF5C1195; Sat, 13 Sep 2014 19:49:38 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6EDDE2; Sat, 13 Sep 2014 19:49:38 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C922C1FE027; Sat, 13 Sep 2014 21:49:35 +0200 (CEST) Message-ID: <54149FC4.7020307@selasky.org> Date: Sat, 13 Sep 2014 21:49:24 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r271504 - in head/sys: dev/oce dev/vmware/vmxnet3 dev/xen/netfront net netinet ofed/drivers/net/mlx4 References: <201409130826.s8D8Q9Wx078339@svn.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 19:49:39 -0000 On 09/13/14 18:54, Adrian Chadd wrote: > Hi, > > Just for the record: > > * I'm glad you're tackling the TSO config stuff; > * I'm not glad you're trying to pack it into a u_int rather than > creating a new structure and adding fields for it. > > I appreciate that you're trying to rush this in before 10.1, but this > is exactly why things shouldn't be rushed in before release deadlines. > :) > > I'd really like to see this be broken out as a structure and the bit > shifting games for what really shouldn't be packed into a u_int fixed. > Otherwise this is going to be deadweight that has to persist past > 11.0. > Hi Adrian, I can make that change for -current, making the new structure and such. This change was intended for 10 where there is only one u_int for this information. Or do you want me to change that in 10 too? --HPS